Say that we have the following file that is owned by the user root and the group root:

-rw-r----- 1 root root 54 2017-12-18 04:21 1.txt

And say that we have a process with a fsuid of root but with a fsgid of some other group other than root.

The user permissions for the file says that the owner user can read it and write to it but not execute it. But I think that since the process have a fsuid of root, then the user permissions of the file does not apply to the process, and so the process will be able to read and write and execute the file, correct?

Now say that we have a process with a fsgid of root but with a fsuid of some other user other than root.

The group permissions for the file says that the owner group can read it but not write to it and execute it. Now I think that in this case the process does not have full access to the file and only the group permissions of the file apply to the process, correct?

2 Answers 2


The rules are as following:

  • If the user is the root-user (UID=0) grant full access
  • If the user is the owner, use the owner-triplet as permission
  • If the user isn't the owner but belong to the group, use the group-triplet as permission
  • It the user is neither the owner nor member of the group, use the other-triplet as permission

So for root it doesn't matter much anyway - but for other users, it's the most specific permission-triplet that applies. So in your example, if the user is both the owner and a member of the group, it's the owner-triplet that's used (not the group-triplet). So if the group got both read-and-write-permission, but the owner only got read-permission; then the owner will only be allowed to read the file - even though his group-membership ought to let him write to it too. Other (non-owner) members of the group, will be allowed to both read-and-write the file.

The owner of a file can always add more permission to himself if he needs to - and sometimes a program may do it for you. For example, if you got a write-protected file (eg. permission r--r-----), some editors will allow you to write to them anyway (usually after a confirmation). The editor is running as you, and as you own the file and can change its permissions, the editor can remove write-protection and allow you to save the file.


It means that it's the root-user who owns the file and got permission to both read and write it - the owner (root) may also change the file's permission. And that members of the root-group are allowed to read it. Other users can neither read, write nor execute the file. (Since it's a text-file, it's probably little point of executing it anyway.)

Many files on a Linux-system got root-user as it's owner and root-group as it's group. Although, traditionally various system-users and system-groups - like bin, sys, proc, operator - owned many files rather than root. For example, the binaries (the executable programs) usually had bin-user and/or bin-group as ownership (eg. bin:bin or root:bin).

The exception to this was executables that had to run as root - they had to be owned by the root-user. Usually programs execute as/with the permission of whomever user executed the program. If you run the command ls, it runs with your permissions, and therefore cannot show directories you're not allowed to list (like the directories of other users). If a command is run with root-permission on the other hand, it got access to the whole system (which is why you don't want to that on most executables).

One good is example is the passwd-command which lets you change password. This is run as root, and gives any user limited access to the files used to store the user-and password-databases.

rwsr-xr-x root:root /usr/bin/passwd

s=x+S, where x is execute-permission, and S is run as owner or run as group, depending if it's set for the owner or group triplet.

So root-user is the owner; and got read, write and execute permission. root-group is the group, and got read and execute permission. While other users also got read and execute permissions. In addition, the executable will run with the permissions of it's owner - ie. root - and not with the permissions of the user executing it (as is normal), thanks to the "s" (u+s) in the owner-triplet.

Another example, this time from BSD (a UNIX OS):

rws-x--- root:wheel /bin/su

This means the the executable su is always run as it's owner - root. That root-user may read, write and execute it. That members of the wheel-group is allwoed to execute it, but not to read (eg. copy) it. And that other users may neither read, write nor execute it. (The command su exists on Linux also, but here all users may execute it - it still runs as the root-user though.)

Other programs may also run as some system-user (and group) - for example the apacheweb-server is often run as the www-data-user (and www-data-group). This way it can't do too much damage if compromised, due to lack of permissions where it doesn't belong.


Your second point is correct, members of the group root can read the file but cannot write or execute it.

Your first point is incorrect - even the root user cannot execute this file. root can easily change the permissions to make it executable, but cannot actually execute it until that step is taken.

An important caveat to note is that with shell scripts or other plain-text scripts, they can be "sourced" for execution without the executable bit being set. In this example, if the contents of the 1.txt file are actually a bash script, even with the 0650 permissions, you would be able to run bash 1.txt and have the commands inside the file executed, effectively running the script and seeming to get around the execution permission bit.

The caveat can be seen here:

# ./myecho
Hi there!
# chmod -x myecho
# ./myecho
-bash: ./myecho: Permission denied
# sh myecho
Hi there!
  • "Your first point is incorrect - even the root user cannot execute this file" This is not true, I removed the x permission (in the user permissions) of a program owned by root and I executed it as root and it executed successfully.
    – Steve
    Dec 20, 2017 at 14:30
  • 1
    Steve - see the edit. You cannot execute files that are marked non-executable, even as root. You can source them in a shell, but you cannot execute them.
    – John
    Dec 20, 2017 at 16:38
  • I didn't execute a shell script, I executed a C program. I executed it in the terminal (that has bash on the other end) like this: ./myProgram, and I double clicked on it in Nautilus (Nautilus was running as root), in both cases it was executed successfully.
    – Steve
    Dec 20, 2017 at 19:14
  • 1
    You're doing something you don't realize, or you're not doing something you think you are. Perhaps you only removed the user-execute bit, not all execute bits.
    – John
    Dec 20, 2017 at 19:35
  • You are right, the group x bit was still on. But this is weird, shouldn't the C program not get executed if the user x bit is not set, and the the group x bit should not matter at all?
    – Steve
    Dec 20, 2017 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .