42

I have the following file:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

I switched the user to root in the terminal, and I have noticed the following behaviors:

  • I can read this file and write to it.

  • I can't execute this file.

  • If I set the x bit in the user permissions (---x------) or the group permissions (------x---) or the others permissions (---------x) of the file, then I would be able to execute this file.

Can anyone explain to me or point me to a tutorial that explains all of the rules that apply when the root user is dealing with files and directories?

ilkkachu
  • 138,973
Steve
  • 827
  • 1
  • 9
  • 15

6 Answers6

50

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 that

Read/write DACs are always overridable. Executable DACs are overridable when there is at least one exec bit set.

And 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 having CAP_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; and CAP_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 that CAP_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:

  • some files in /proc and /sys, since they're not really actual files
  • SELinux and other security modules that might limit root
  • chattr immutable +i and append only +a flags on ext2/ext3/ext4, both of which stop even root, and prevent also file renames etc.
  • network filesystems, where the server can do its own access control, e.g. root_squash in NFS maps root to nobody
  • FUSE, which I assume could do anything
  • read-only mounts
  • read-only devices
ilkkachu
  • 138,973
  • Surprising that the source file comment doesn't seem to be mirrored in the capabilities(7) man page - consider filing a bug report! – Toby Speight Dec 21 '17 at 16:41
  • @ilkkachu As it has been shown, root have rw- permissions on (almost) any file, and to get the x permission, then the x bit must be set on either user/group/others permissions on the file. But what about the directories, does root have rwx permissions on any directory (even if a directory have no permissions at all (----------))? – Joseph Dec 23 '17 at 14:15
  • @Joseph, yeah, CAP_DAC_OVERRIDE allows overriding all directory permissions, so you do get to read, write and access directories (i.e. list the contents, create and unlink files). The comment I quoted about exec bit is in the context of files (only). – ilkkachu Dec 23 '17 at 15:46
17

That's exactly like you've noticed for default permissions:

  • Read & write:
    By default, Root user can access any file in the system. You may remove this access by changing attributes like explain here: chattr. This is then linked to capabilities.

  • Execute:
    Root user doesn't have execution permission unless at least one of the execution bits is set.

Kevin Lemaire
  • 1,689
5

The myFile.txt is obtained by chmod 000 myFile.txt .

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- mean there is no permission for user , group and other.

The root user has an unrestricted capability to modify this file. The read/write is granted. To execute this file the root user need to make it executable anyway. (chmod 100 , 010 or 001)

GAD3R
  • 66,769
3

Execute mode is treated a little bit differently from the other modes.

Read and write permissions are used to enforce security policies. The root user is generally immune from security restrictions (there are some exceptions, like immutable files, and modern features like capabilities have made this more fine-grained), which is why another name for this account is the "superuser".

Execute permission is more of an advisory mode, distinguishing whether the file is intended to be executable or is just data. Because of this, even the root user obeys it -- there's no point in executing a data file. If none of the execute permissions are set, root can't execute the file; if any of them are set, he can. Of course, since root also has permission to change any file's permissions, the account can make a file executable if it wants to (unless the filesystem is read-only).

BTW, scripts are an interesting case in this. Scripts are data files for the relevant interpreter. If the script has a #! line, you can execute it as a program -- the interpreter named in the shebang is run with the script filename as an argument. But this will only be done when execute permission is set. On the other hand, you can just run the interpreter directly, e.g. /bin/bash scriptname. Interpreters only care if they can read the file, they don't check execute permissions.

Barmar
  • 9,927
0

Let me explain you theoretically.

root user is the king of the operating system.

If a file or directory have any permission like X for execute but nothing else and some one like Steve user have own the file then root can also execute the file.

Always remember, in Linux root can do anything, there is no restrictions on root.

Hassan Hashmi
  • 139
  • Not anything. If a file has an immutable attribute, for example, then even root can't change it (unless he explicitly removes that attribute). – Ruslan Dec 21 '17 at 15:03
  • @Ruslan yes, but it's too much exceptional case he is new so I explain him as a basic, by default these kind of attributes do not occur. – Hassan Hashmi Dec 21 '17 at 16:10
0

On macOS, due to SIP (System Integrity Protection), not even root can write to certain directories. /usr/bin is an example. If you try to write there as root, you will get:

touch: /usr/bin/foo: Operation not permitted

So, this is one exception to the rule. Without rebooting, going into recovery mode and disabling SIP, root can't write certain files.

aremmell
  • 101