I would check this page out. It talks about file permissions in depth.
But to answer your question directly, no:
The super user "root" has the ability to access any file on the system.
In your example for instance if the file is owned by say bob
and the group owner was also bob
, then you would see something like this:
-r--r-xrw-. 1 bob bob 8 Jan 29 18:39 test.file
The 3rd bit group the (rw) would also apply to root, as root being part of the others
group. If you tried to edit that file as root you would see that you have no problem doing so.
But to test your theory even more, if the file was owned by root:
-r--r-xrw-. 1 root root 8 Jan 29 18:40 test.file
And you again went to edit the file, you would see that you still have no problem editing it.
Finally if you did the extreme:
chmod 000 test.file
ls -lh test.file
----------. 1 root root 8 Jan 29 18:41 test.file
And you went again to edit the file you would see (at least in vi/vim) "test.file" [readonly]
. But you can still edit the file and force save it with :wq!
.
Testing @Stéphane Chazelas claim with a shell script file:
#!/bin/sh
echo "I'm alive! Thanks root!"
[root ~]# ls -lh test.sh
----------. 1 atgadmin atgadmin 31 Jan 30 10:59 test.sh
[root ~]# ./test.sh
-bash: ./test.sh: Permission denied
[root ~]# sh test.sh
I'm alive! Thanks root!
@Shadur already said it so I'm just going to quote instead of restating it:
Note: The execution bit is checked for existence, not whether it's applicable to root.
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 apache
web-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.
Best Answer
Privileged access to files and directories is actually determined by capabilities, not just by being
root
or not. In practice,root
usually has all possible capabilities, but there are situations where all/many of them could be dropped, or some given to other users (their processes).In brief, you already described how the access control checks work for a privileged process. Here's how the different capabilities actually affect it:
The main capability here is
CAP_DAC_OVERRIDE
, a process that has it can "bypass file read, write, and execute permission checks". That includes reading and writing to any files, as well as reading, writing and accessing directories.It doesn't actually apply to executing files that are not marked as executable. The comment in
generic_permission
(fs/namei.c
), before the access checks for files, says thatAnd the code checks that there's at least one
x
bit set if you're trying to execute the file. I suspect that's only a convenience feature, to prevent accidentally running random data files and getting errors or odd results.Anyway, if you can override permissions, you could just make an executable copy and run that. (Though it might make a difference in theory for setuid files of a process was capable of overriding file permissions (
CAP_DAC_OVERRIDE
), but didn't have other related capabilities (CAP_FSETID
/CAP_FOWNER
/CAP_SETUID
). But havingCAP_DAC_OVERRIDE
allows editing/etc/shadow
and stuff like that, so it's approximately equal to just having full root access anyway.)There's also the
CAP_DAC_READ_SEARCH
capability that allows to read any files and access any directories, but not to execute or write to them; andCAP_FOWNER
that allows a process to do stuff that's usually reserved only for the file owner, like changing the permission bits and file group.Overriding the sticky bit on directories is mentioned only under
CAP_FOWNER
, so it seems thatCAP_DAC_OVERRIDE
would not be enough to ignore that. (It would give you write permission, but usually in sticky directories you have that anyway, and+t
limits it.)(I think special devices count as "files" here. At least
generic_permission()
only has a type check for directories, but I didn't check outside of that.)Of course, there are still situations where even capabilities will not help you modify files:
/proc
and/sys
, since they're not really actual fileschattr
immutable+i
and append only+a
flags on ext2/ext3/ext4, both of which stop even root, and prevent also file renames etc.root_squash
in NFS maps root to nobody