Who are "others" in Linux permissions, and what does "execute" mean?

Question

I could not find the answers on these three questions:

• 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?

• What is the difference between "execute" and "read"?

• What are the default file permissions for the whole system after a clean install (e.g. in Ubuntu)?

Answer 1

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 chown)

• 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 /var/www anymore.

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 /var/www to 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
$ ./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 /bin. Run 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 /etc).

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.

Answer 2

Just want to add that execute permission have different effective meanings for directories:

For files:

• Read: If the file contents can be read
• Write: If user or process can write to the file (change its contents)
• Execute: If the file can be executed

For folders:

• Read: If the directory listing can be obtained
• Write: If user or process can change directory contents somehow: create new or delete existing files in the directory or rename files.
• Execute: If user or process can access the directory, that is, go to it (make it to be the current working directory)

No, there is no separate delete permission for directories.

(Got this information here.)

Answer 3

I'm no Linux expert, but I try to answer nonetheless.

Each file system entry has an associated user and group. The user's permissions are handled by the "user" flags. User permissions of users which are part of the same group are handled by the "group" flags. All other users are handled by the "others" flags.

"read" means what it says. "execute" means that you can launch the file (e.g. a command) or that you can list the directory.

Regarding the default permission, I'm not sure. I guess, it can be configured somehow and hence might be different for each user.

Answer 4

To give you a decent answer to question 2, at least, here is a summary-table showing what you can/cannot do:

+--------------------------------------------------+
| Execute Yes (./file.sh) | Read Yes (vim file.sh) |
|--------------------------------------------------|
| Execute Yes (./file.sh) | Read No (ERROR)        |
|--------------------------------------------------|
| Execute No (ERROR)      | Read Yes (vim file.sh) |
|--------------------------------------------------|
| Execute No (ERROR)      | Read No (ERROR)        |
+--------------------------------------------------+

What's important to remember, is that it is not the USER reading file file into memory in order to execute it, it is the KERNEL doing it on the USER's behalf.

Answer 5

It may be tricky if you want to exclude all others. Look at this list from my /etc/passwd file (permissions and whatnot removed for clarity):

root daemon bin sys sync games man lp mail news uucp proxy www-data backup list irc gnats libuuid syslog messagebus usbmux haldaemon nobody

a {this is me, and below here are things I installed, above all came with the system}

avahi mysql pulse rtkit saned timidity didiwiki

So for instance, remove permissions from lp or uucp and you'll break printing. remove permission from bin, sys, or daemon and probably a lot of stuff will break. irc, games, mail, news, and backup could probably be safely removed (unless you're using those through the system, not a browser). the rest i leave to your search engine skills.

This is ubuntu/bodhi linux though, and other systems may have fewer extras. all these others however are to prevent having to run everything as root. i imagine its possible to create a system where each file can be read/written/executed by only one of the system users (bar root) but i'm not sure its been tried.

Execute is permission to run code. Read is permission to look (and copy?) only.