From https://security.stackexchange.com/a/67218/

In Unix and Linux there are two levels of permissions: standard user and superuser (usually called root).

The standard user has access only to the files that he has permissions for, by ownership, group membership or ACL.

The superuser has permissions to everything (we'll ignore stuff like SELinux and the like for this answer) without limits within the userspace.

When a process has an effective or real uid being root and tries to access a file, is it still subject to permission bits of the file? Or like the quote says (if I understand it correctly), having euid root will override the permission bits of the file?

For example,

  • when the owner of the file is not root and its group doesn't match the effective group or supplementary groups of the process, will the permission bits of the file for "others" apply to the process? If the file doesn't allow others to read or write or execute, can the process still read or write or execute?

  • when the owner of the file is root, and the permission bits of the file for "user" doesn't allow read, write or execute, can the process still read, write or execute the file?

Is it possible to make a process with effective or real uid being root unable to access a file? For example, by changing the permission bits of the file?



In traditional Unix, root can do anything.

However on modern Linux (maybe other Unixes), it now has capabilities. The capability being discussed here is CAP_DAC_OVERRIDE, any process with this capability will ignore file permissions (with exception of x, see other answers).

Most systems will be setup in backward compatible mode, so that when a processes changes its effective user ID to root, it will gain all capabilities, and when the effective user ID changes from root it will drop capabilities.

There are ways to avoid dropping capabilities, this can be used to pass on some capabilities to a non-root process. There is also a way to gain capabilities without becoming root, this works in a similar way as how a process becomes root.

It is the effective user ID, that matters, the real and saved user IDs only give you permission to copy these IDs to one of the other IDs (for example to the effective user ID).

SE_linux and namespaces/cgroups, can restrict what root can do.


Root will have access to everything, regardless of permission bits. An exception is that a root process will not attempt to execute a file if none of the execute bits are set, and restrictions set by SELinux.

However, root will still be able to set desired execute bits and change SELinux rules, so there is nothing you can do to prevent root from accessing your files.


From "man path_resolution"

On a traditional UNIX system, the superuser (root, user ID 0) is all-powerful, and bypasses all permissions restrictions when accessing files.

  • Thanks. Can you point me to some references? – Tim Sep 6 '18 at 16:43
  • man path_resolution – RalfFriedl Sep 6 '18 at 17:13
  • Thanks. But it doesn't mention the execution part. – Tim Sep 6 '18 at 17:20
  • I'm sure you will find a reference somewhere. I also just now verified it. It's not so much about denying root the right to execute a file, because root can always set execute rights. It's more about preventing the accidental execution of a file that is not meant to be executed. Of course it is never a good idea for root to execute arbitrary files even if they have the execute bits set. – RalfFriedl Sep 6 '18 at 17:32
  • I thought that you can restrict root, with se_linux. You certainly can with c_groups and namespaces (as used by docker). – ctrl-alt-delor Sep 6 '18 at 18:01

When a process has an effective or real uid being root and tries to access a file...

It's only the effective UID that matters for filesystem access, not the real UID. A process holding a privileged UID can shuffle the real and effective UIDs around to temporarily drop privileges.

# perl -MEnglish -e '$EUID = 65534; system "id"; system "cat /etc/shadow"'
uid=0(root) gid=0(root) euid=65534(nobody) groups=0(root)
cat: /etc/shadow: Permission denied

But other than that, you're right, being privileged allows accessing files regardless of the permission bits. (Apart from the fact that executing a file doesn't work unless it has at least one x bit set, but that's really nothing but a convenience. If you're privileged, you can usually just copy the file away and run it, or change the permissions first.)

See e.g. the final part of the Linux man page path_resolution(7) ("Bypassing permission checks: superuser and capabilities") or the text in POSIX ("4.5 File Access Permissions").

Like the latter hints, and the former states in plain, the actual check for being privileged may be other than just the UID. On Linux, it's actually the CAP_DAC_OVERRIDE capability (or CAP_DAC_READ_SEARCH to a lesser extent). I don't know the details of other systems.


You cannot hide anything from root, unless you use encryption, and even then root can still delete it!

Sorry! ¯\_(ツ)_/¯


For the privileged user only the x bit is evaluated.

This means that in order to permit the super user to execute a file, at least one x bit must be set.

All other permissions are ignored for the super user.

  • Thanks. Can you point me to some references? – Tim Sep 6 '18 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.