Hot answers tagged

243

First of all a minor terminology nitpick: chmod doesn't remove permissions. It CHANGES them. Now the meat of the issue -- The mode 777 means "Anyone can read, write or execute this file" - You have given permission for anyone to do (effectively) whatever the heck they want. Now, why is this bad? You've just let everyone read/modify every file on your ...


86

One major thing is that there are many tools like ssh/sudo that check the filesystem permissions for key config files. If the permissions are wrong, these tools are designed to fail, as this would indicate a serious security problem. On my Debian test system and perhaps on others, the ability to login fails, probably because the login binary or something ...


48

Accessing the contents (or more specifically file metadata except for filename) of a directory requires that the directory have the execute bit set. Your recursive chmod removed that permission, so you lost that access. If you are using the -R option of chmod is better to avoid using the numeric version of the permissions, and instead run (using your ...


31

After more research it seems like another (possibly better way) to answer this would be to setup the www folder like so. sudo usermod -a -G developer user1 (add each user to developer group) sudo chgrp -R developer /var/www/site.com/ so that developers can work in there sudo chmod -R 2774 /var/www/site.com/ so that only developers can create/edit files ...


25

@ signifies that the file has extended attributes. Those attributes are usually used to signify that the file came from a package, was downloaded from the internet, etc. ls -al@ imap.a will show you the extended attributes that are saved for that file.


17

A file with -rwx-wx-wx permissions has read/write/execute permissions for the owner, and write/execute (but not read) permissions for everyone else. If it's a script (usually a text file with a #! on the first line), then it can't be executed by others, because executing a script really executes the interpreter, which must be able to read the script. (The ...


15

No need for scripts. // Directories: find . -type d -exec chmod XXX {} \; // Files: find . -type f -exec chmod XXX {} \;


15

I would actually consider doing a full reinstall of the system. Even if you manage to get most permissions right and that things seem to work there will most likely be some special permissions laying around, just waiting to cause trouble. Alternatively I'd compare the permission with a second, possibly freshly installed, machine. Shouldn't be to hard ...


13

dpkg-statoverride is the management tool for a database maintained by dpkg that contains owner and mode settings for given file paths. Invoked as in your question, it will do two things: Set the owenrship/mode for the given files immediately if they exist (--update) and store a new entry in the override file (--add). The latter ensures that further dpkg ...


13

find . -type d -perm 777 -exec chmod 755 {} \; (for changing the directory permission) find . -type f -perm 777 -exec chmod 644 {} \; (for changing the file permission) If they did not have 777 permissions, we easily remove the -perm 777 part.


13

From the Wordpress documentation: If you have shell access to your server, you can change file permissions recursively by using the following commands: For Directories: find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; For Files: find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;


12

You can set the perms using the --chmod parameter e.g. --chmod=Du=rwx,Dgo=rx,Fu=rw,Fog=r will force the permissions to be set to 755 for Directories and 644 for Files.


12

Depending on your version of chmod, you may be able to do this: chmod -R . ug+rwX,o+rX,o-w Note the capital X. This sets the executable bit on directories and files that already have any of the execute bit already set. Note that you can only use capital X with '+', not '=' or '-'.


10

Why not leave system files readable? Obscurity is not security Your system should be just as secure even if people know how it works. If you're relying on details being kept secret to keep your system secure it's just a matter of time before it's broken. How will you work? It is generally accepted that you should use the root account as little as ...


10

Because many programs might need access to those files. As an example, whenever you do an 'ls -l', the system will look up /etc/passwd to translate between numerical uid and the username. This wouldn't work if the user didn't have any rights to read that file. Even more important, if you would take the read rights for every file, you couldn't even login ...


10

The difference between 777 and 775 is the writable attribute for the world-group. The big risk with 777 is that any user on your server can edit the file. 775 does not have this risk. Don't erroneously assume that the "world writable" flag means everyone can write to the file - only the users on that server can. So on a private server, this poses less risk. ...


10

find / -type d -perm 777 -print


9

Reinstall is the best option. I personally would always have the nagging feeling of something not done right even if the following work. Use another Ubuntu system to reference your permissions. Same Ubuntu version and architecture. reference$ find / ! -type l \ -path "^/tmp" -prune \ -o -path "^/dev" -prune \ -o -path "^/sys" ...


9

Yes. In order for another user to traverse into any subdirectories, it needs to read the base directory. If it doesn't have permissions (ie: 700), it won't be able to read anything in there. Also make sure that the base directory (/home/foo) is owned by the user foo. A user, bar, should not be able to access it.


9

You can get rid of the find commands by using chmod's X flag: execute/search only if the file is a directory or already has execute permission for some user (X) This allows you to set the same permissions on files and directories, with directories additionally being executable, with a single command: $ chmod -R a+rX $dir


9

The Unix default permissions for a newly created file are 0666. The Unix default permissions for a newly created directory are 0777. If you do not want the default base permissions set an appropriate umask value. The only thing you can't easily do with umask is create a file which is by default executable (which, by simple common sense, is something you ...


8

In your case it might not have to be as complicated as others has made it out to be (though find is indeed a good tool for this sort of thing in general). The difference between the modes are the execute bit. If it is the case that no files already has the execute bit set, then you can do it in a single invocation of chmod, just as you asked. chmod -R ...


8

I do find a script useful since it's often useful to change both file and directory permissions in one swoop, and they are often linked. 770 and 660 for shared directories on a file server, 755/644 for web server directories, etc. I keep a script w/ the most commonly used mode for that type of server in root's bin/ and just do the find manually when the ...


8

Deleting a file/directory changes the contents of the parent directory, hence, if you don't want MainFolder to be deleted, you want to ensure that the intended user does not have write access to the parent dir of MainFolder. Assuming this structure: /some/dir/ParentDir/MainFolder/SubFolder You'll want to run something like this to prevent deletion (for all ...


8

Items #1 and #2 are how Ubuntu works already. To achieve #3 you need to set the umask (wikipedia entry) to 0022


8

If you're using bash then setting dotglob will make * also match files that begin with a .. shopt -s dotglob echo *


8

First, use the chgrp command instead of chown and that will work. In the case of using chown.....For security reasons in most Linux contexts, any ownership change is restricted to the root user eventhough you are marked as the owner of the file, directory, etc or not. In one case, this is to prevent users from evading quotas by setting the file permission ...


8

I ended up using file_open_mode=0777 local_umask=022 on the vsftpd.conf. The problem was that both FTP user and www-data user needed permissions to write, so i had to join www-data and ftpuser to www-data usergroup, and CHMOD -R 775 all the files on /var/www - that way, with 775 CHMOD, the group would have permission to read, write and execute. Now its ...


8

The obvious problem is that /srv/git/test does not have the executable x bit set for owner and group. Thus it is not possible to traverse the directory. Resolve the issue with: chmod ug+x /srv/git/test


7

You would need to run 2 commands I believe. This is one way to do it: # find . -mindepth 1 -type d | xargs chmod 700 # find . -mindepth 2 | xargs chmod 700 The first does directories at the current directory level and deeper. The second does all files and directories deeper than the current directory.



Only top voted, non community-wiki answers of a minimum length are eligible