Fr. Br. George told in one of his lectures (it's in Russian) that there are some access rights that superuser can not violate. That is there are some access right which can forbid superuser doing something.

I was not able to find this information on the Internet and I'm curious what they are. This is probably something related to the system's core execution, isn't it? Maybe he can not stop some system processes? Or maybe he can not run a process in real mode?

This question is no related to SELinux (George was talking about it right before the question).

  • 2
    A "privilege" or "permission" is a right to do something, a right that can be granted to specific user accounts. In UNIX and Linux (excluding hardened versions such as SELinux), root has all rights. There's no right that can be granted to root, and therefore no right that can be taken away from root.
    – MSalters
    Oct 26, 2015 at 14:00
  • 1
    @MSalters, pardon? One can certainly keep UID 0 while still revoking process capabilities. Oct 26, 2015 at 17:38
  • ...set SECBIT_NOROOT, and being uid 0 no longer grants one capabilities automatically. Oct 26, 2015 at 17:44
  • So many answers -- would it make sense to turn this into a community wiki, or should someone write a summary answer? Oct 26, 2015 at 23:00
  • 1
    @SimonRichter I'm also going to as George to tell us what he meant in his lecture.
    – Kolyunya
    Oct 26, 2015 at 23:04

8 Answers 8


acess denied to root:

root can be denied direct network access. This is useful on internet connected hosts, as it requires that you login as smith, then sudo.

some stuff root can't do:

This is NOT for a lack of privilege. I can't see anything root couldn't do, however some technical issues might be experienced as "forbidden".

I am root, why can't I create/delete this file, while ordinary user can?

You are on a NFS/samba share, and you weren't give specific (access=) authorization. Ordinary user fail to common law. (see local vs remote root below)

I am root, why can't I kill this process?

There is a pending I/O and physical drive/remote LUN have been disconnected, process can only be killed by reboot.

I am root, how do I get archemar's password?

You can su - archemar all right, or change archemar's password without knowing the previous one, but you can't read it (short of a key logger), since passwords are stored using a one-way hash.

local vs remote root

  • You can be root on your station/PC, and use a company/college/university/provider NFS share.
  • Next you can have only a non-root login on computer exporting NFS.


cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

simply log on NFS server, run ./bash and you are root on company/university server.

  • Case 1 is basically an error because you're only root locally, not necessarily on other systems. Case 2 and 3 aren't privileges (they can't be granted to anyone). So +1, your first sentence appears to be correct.
    – MSalters
    Oct 26, 2015 at 13:57
  • Technically, root on local machine could do anything it likes with the same privilege as local user, by su - username if nothing else. I'm never sure why they bothered making root unable to write network shares like that; it seems rather pointless.
    – Tom Hunt
    Oct 26, 2015 at 14:48
  • 4
    It's the age old question "Can root create a password even he can't access?"
    – corsiKa
    Oct 26, 2015 at 15:56
  • 5
    @TomHunt, one of the reasons not to give root access to NFS shares is to prevent the creation of "suid root" binaries on the remote server, something that can be leveraged into complete remote access to the server.
    – Mark
    Oct 26, 2015 at 18:24
  • 1
    Killing a process in uninterruptible wait doesn't seem like a right to me. It's something that you just can't do. Like writing to a full filesystem. Oct 26, 2015 at 19:27

In the usual case, this is incorrect - the superuser has privileges / permissions to any functionality the system provides(1). Where this rule breaks down is when you throw SELinux into the mix. With SELinux, it is possible to restrict even root's privileges to disallow certain actions. However, the specific actions disallowed are highly dependent on the local machine's SELinux configuration, so even with SELinux, this question cannot be answered in the general sense.

(1) - if a system does not provide a given feature, e.g. there is no real-time kernel functionality, then I am considering the statement "root does not have access to this functionality" to be false, since that statement relies on a false assumption (namely that the given feature is available to anyone on that system)

  • 1
    Thank you for your answer, John! But he explicitly stated that this question is not related to SELinux...
    – Kolyunya
    Oct 26, 2015 at 12:08
  • Then barring further details, I'm going to have to consider the statement that root doesn't have access to certain functionality to be false. (I'm not considering the case of the OS being locked out of the BIOS or similar by BIOS security.)
    – John
    Oct 26, 2015 at 12:10
  • You also have the complication that root controls the SELinux configuration. If I (as root) am blocked in an action I can modify SELinux to allow the action and then change it back afterwards. Might get away with it depending on where the log trail is stored.
    – doneal24
    Oct 26, 2015 at 15:51
  • 2
    Not necessarily true. Take away its CAP_NET_ADMIN, and being uid 0 still doesn't let a process change network configuration. (Likewise for CAP_SYS_ADMIN and the abilities it controls, etc). Oct 26, 2015 at 17:39

On one hand, there are things that no user can do, such as

  • hard-linking directories (because of file system limitations)
  • writing to an already burned CD-ROM (because physics)

But those are not privileges, because they cannot be granted, they are just not possible for anyone.

Then there are restrictions for the entire system or parts of it that can be turned on or off.
For example, on OS X there is an option to only allow code to run if it has been signed by Apple.

I don't consider this an actual privilege either, because no user can have it if the superuser can't. You can only globally disable it.

Your idea of a file without the executable bit would also fall in this category, as literally, no one is able to do that, and no one can be granted that permission.
And even when giving another user or group the permission to execute that file, but not root or a user group root is in, root will still be able to execute that file (tested on OS X 10.10, 10.11, and Ubuntu 15.04 server).

Apart from those cases, there is barely anything root cannot do.
There is, however, a thing called kernel mode (as opposed to user mode).

As far as I know, on a sane system only the kernel, kernel extensions, and drivers run in kernel mode, and everything else (including the shell from which you log in as root) runs in user mode.
You could therefore argue that "being root is not enough". However, on most systems the root user is able to load kernel modules, which will in turn run in kernel mode, effectively giving root a way of running code in kernel mode.

There are systems, however, (like iOS) where this is not (arbitrarily) possible, at least not without exploiting security holes. This is mostly due to increased security, like code signing enforcement.
For example, there are AES encryption keys built into the processors of iDevices, which can only be accessed from kernel mode. Kernel modules could access those, but the code in those kernel modules would also have to be signed by Apple in order for the kernel to accept them.

On OS X, since version 10.11 (El Capitan) there is also a so-called "rootless mode" (although the name is misleading because root still exists), which effectively forbids root certain things that installers can still do.
Quoting from this excellent answer on AskDifferent:

Here's what it restricts, even from root:

  • You can't modify anything in /System, /bin, /sbin, or /usr (except /usr/local); or any of the built-in apps and utilities. Only Installer and software update can modify these areas, and even they only do it when installing Apple-signed packages.
  • 1
    Actually, you can can run an executable without the execute bits set: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hello gives the expected Hello, World! output,
    – doneal24
    Oct 26, 2015 at 16:51
  • @DougO'Neal But isn't /lib64/ld-linux-x86-64.so.2 the actual executable then, and ./hello just an argument to it? Because that's like passing a text file containing PHP code to the PHP interpreter... or like running a bash script using bash ./my_script...
    – Siguza
    Oct 26, 2015 at 16:57
  • 1
    @DougO'Neal That used to work, but was disabled in recent versions of glibc (to prevent it from being a trivial bypass of noexec mounts).
    – user130738
    Oct 26, 2015 at 18:09
  • @duskwuff How recent a version of glibc? This still works under Ubuntu 14.04.
    – doneal24
    Oct 27, 2015 at 13:56
  • 1
    Apple did not add it to ln but the system class that ln uses e.g. link do allow this see stackoverflow.com/a/4707231/151019 This is the way Time Machine works
    – mmmmmm
    Oct 28, 2015 at 11:06

The "system core execution" you're mentioning is well under root's control e.g. via loadable kernel modules. Of course, this assumes loading kernel modules is supported by the kernel, noone can perform actions which are not feasible, even root.

The same is true for system processes. root is allowed to kill any process, but it's impossible to stop a process running in kernel mode without compromising kernel integrity, so it's simply unfeasible to stop such processed immediately. Note that root will not be denied to kill those processes, killing itself will simply have no effect.

Finally, the real mode: Linux kernel has no support for it, so again, noone can do the infeasible, not even root.

@Siguza mentioned execution of files without the x permission, which is quite possible for the root user:

/lib/ld-linux.so.2 /path/to/executable
  • ...but a uid-0 process can lose the ability to load new kernel modules (or hotpatch them in through /proc/kmem) via capability revocation. Oct 26, 2015 at 17:41

One example could be modifying of immutable file: You can set a file attribute i with chattr that makes the file immutable even for root. For example:

# whoami
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Note that the file appears as normal writable file in ls -l output:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

To see the i attribute, you have to use lsattr:

# lsattr god
----i----------- god

The manual page of chattr states following about the i attribute:

A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Though, root can easily undo the immutability:

# chattr -i god
# rm -v god
removed ‘god’
  • The Linux kernel does not properly implement the BSD securelevel facility (anymore), giving you diminishing returns on immutable and append only attributes. With securelevel, these bits cannot be reset once the system is in a multiuser runlevel, so the admin would have to shut down and use a local console, which would stop network attackers. Oct 26, 2015 at 22:59

On FreeBSD, you can't use gmirror on an already mounted partition, even as root :

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Can't store metadata on ad4s1: Operation not permitted.

You have to set a sysctl (kern.geom.debugflags=16) to be able to do it.

root is a privileged user, but these rights are given by kernel. So the kernel has got more privileges than root.


Assuming collaboration from the root user itself, root can be prevented from accessing FUSE mounts (with the allow_other or allow_root options), but this is because FUSE was designed to act this way. Since FUSE resides on a virtual layer, it can return any error it likes based on logic, as opposed to common block device modules that strive to be as transparent and thin as possible, delegating permissions to another layer.

This does not prevent the root user from disabling the option, or replacing the FUSE module with one that silently discards the option, unless you make the filesystem read-only. However, this only leads to a "who watches the watchmen" situation: how can you validate that the system is not lying? Your shell might even be sitting in a chroot that shows you a legitimate FUSE module, while the kernel is actually running a malevolent version of it.


I would say that the inability to execute non-executable files is trivially a limitation, as it depends on file permissions. (It is possible to get around this using /lib64/ld-linux-x86-64.so.2 for a nonexecutable file, but not a file on a no-exec mount)

There's also the issue of mandatory file locks, which prevent file editing if a file is currently being used by a process, although the super user can kill the process.

At one point, the super user could not unmount a device while the device was busy, but this can now be done using a lazy umount.

Other limitations are:

cannot modify immutable files, and can only append to append-only files (linux allows the super user to remove the immutable and append only flags at any run-level, however, partly defeating the purpose of them)

cannot write to a read-only mount, or execute anything on a no-exec mount

cannot bind an unbindable mount

cannot remount a file system as read-write if its block device is read-only

cannot stat anything on a fuse mount owned by another user, unless it's mounted allow-other or allow-root

cannot violate SELinux settings

deliberate limitations inherent in the system itself, which affect root:

cannot directly set the c-time of a file (or the birth time, if it's ever implemented)

cannot view passwords as plain text

You must log in to answer this question.

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