Tag Info

Hot answers tagged

221

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 ...


85

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 ...


27

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 ...


22

@ 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

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 ...


15

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


12

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 ...


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

find / -type d -perm 777 -print


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

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 ...


9

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. ...


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

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.


8

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


8

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

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


8

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


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

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


7

PHP scripts run on the webserver. Leaving the permissions that way will make your web server user (www-data or apache) able to write on those files. In case of your script has some bug or vulnerability, those permissions will allow the web server (and thus, external agents) to change the contents of the files and filesystem. Things that can happen: Loss of ...


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.


7

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 ...


7

I'm not sure whether it's "right", but here's what I do on my server: /var/www contains a folder for each website. Each website has a designated owner, which is set as the owner of all files and folders in the website's directory. All of the users that maintain the website are put into a group for the website. This group is set as the group owner of all ...


7

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.


7

Posix ACLs are the only clear-cut elegant way to do this, this is how I deal with shared read/write resource conflicts particularly on web-based systems. Here is a running example. In my example I have a directory called /var/www/html/share. In addition I have the users alice, bob, deploy and bower First, I have created a group called html and then added ...


7

Replace -avz with -rltvz. (The -a option is equivalent to -rlptgoD.)


7

Better, shorter, fancier than what ? cd /directory find . -type d -exec chmod 0755 {} + find . -type f -exec chmod 0664 {} +


6

With those permissions, only the owner of the file can execute it. Other users can write to it, but not execute it (as execution in this case implies being able to read it) but they can write to it as a sort of black box: user1:~$ cd /tmp user1:/tmp$ echo "hostname" > testfile.sh user1:/tmp$ chmod +x testfile.sh user1:/tmp$ ./testfile.sh ...



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