Who is "others", if we give all services on our server a user, "others" don't exist right? For example, if we put Apache to a user, and we set
/var/www chowned to
apache, and we enter
chmod 700 it should work, right?
Here's how the permissions work, explained in a very brief way:
The first digit is for the actual owner of a file (check who's owning a file with
ls -l and modify it with
The second digit is for the group of the file (although the owner of a file must not necessarily be in the same group that owns the file)
The third digit is anyone else, meaning not the file owner and everyone not in the group.
So if you
chmod a file to 700 and it's owned by
apache, even your "normal" user won't be able to read, write or execute it. This is very restrictive and only needed in rare occasions – for example, when you want to secure your SSH private key, it gets
600 permissions. For Apache, this might even result in other problems, apart from the fact that with your normal user account, you wouldn't be able to edit any files in
So, generally speaking, you shouldn't need to remove read permissions (
x00) for others.
You could let
apache own the
/var/www directory, but with
644 (read-only for others) maybe. Another approach I often use is adding your own user and the Apache user to a new
www-users group, and then chmodding files in
775. This way, both you and Apache can write to the files. See here for more info: Group permissions for apache
What is the difference between "execute" and "read"?
Executable files can be run directly by a user – straight from the shell. To demonstrate this, let's write a short file and call it "test". Add the following content:
echo "I am executable"
Save the file. Now, in your shell, try to enter
./test. You will get a "-bash: ./test: Permission denied" error. This is because by default, newly created files do not carry execute permissions. If you add the execute permission, it'll work.
$ chmod +x test
I am executable
Now, this was just a test script, but typically, all binary files (like compiled programs) also need the execute permission set, so you can actually run and do something with them, and not only read.
These are for example the system programs mostly found in
ls -l /bin to inspect their permissions. As you can see, they're owned by
root, and you can't change them, but you can always execute them.
So, this is somewhat a security feature too, since you can restrict execution of certain scripts and binaries for some users.
To learn more about Unix permissions, read the Wikipedia article. The basic permissions you know as "read-write-execute" have been around for a long time, but are just part of what you call Access Control Lists – which offer much more functionality than this.
What are the default file permissions for the whole system after a clean install (e.g. in Ubuntu)?
They vary by directory and owner. Some files and directories are system-reserved and owned by
root. In most cases, you'll be able to read them with your normal user account nonetheless.
Other directories like your home folder obviously belong to your user. It could make sense to deny read permissions to other users on a machine if it's shared between multiple persons – after all, you don't want your private stuff exposed.
Finally, some files are executable by default (e.g. in
/bin), but others are not (e.g. configuration files in
The Filesystem Hierarchy Standard specifies the intended usage for directories found in Linux systems. You can almost "guess" what the permissions should be based on what you want to do with a directory.