In Linux, a process that have a non-root user can have some capabilities assigned to it to increase its privileges.

And a process that have the root user have all of the capabilities available, but can such a process have some of its capabilities removed (either manually or automatically in certain situations)?


Yes, the idea of capabilities is that the user id itself doesn't give any special abilities. An UID 0 process can also drop unneeded capabilities. It would still retain access to files owned by UID 0 (e.g. /etc/shadow or /etc/ssh/sshd_config), so switching to another UID would still likely be a smart thing to do in addition.

We can test this with capsh, it allows us to drop capabilities as requested. Here, the last part is run as a shell script, and we can see that the chown fails since the ability to change file owners (CAP_CHOWN) was dropped:

# capsh --drop=cap_chown -- -c 'id; touch foo; chown nobody foo'
uid=0(root) gid=0(root) groups=0(root)
chown: changing ownership of 'foo': Operation not permitted

The capabilities(7) man page mentions that the system has some safeguards in place for setuid binaries that don't know about capabilities and might not deal well with a situation where some are permanently removed. See under "Safety checking for capability-dumb binaries".

The same man page of course contains other useful information on capabilities, too.

  • I often read in Linux tutorials a statement like this: "The root user can do anything". Can we say that this statement is technically incorrect, and the correct thing to say is that a process that have all of the capabilities available is the one that can do anything (regardless if it is a root process or not)? – John Feb 27 '19 at 5:40
  • @John, yep. But not many systems use capabilities to a large extent, so in that sense it's not too incorrect. Though of course, if you're running, say SELinux, then, again it's possible that root can't do everything. – ilkkachu Feb 27 '19 at 8:47

Programmatically adjusting capability sets

A thread can retrieve and change its capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:


  1. The new permitted set must be a subset of the existing permitted set (i.e., it is not possible to acquire permitted capabilities that the thread does not currently have).
  2. The new effective set must be a subset of the new permitted set.

-- capabilities(7)


There are a few other things you can do.


NFS shares can be made available with the root_squash flag.

In this way, a network share can be mounted but a root user on the client is not given root access to files hosted on the server that makes the NFS available. In this you can make files accessible to another host and even if a user on that host has root on their box, your content is still safe.

This is useful in Enterprise environments for example if you want to allow your Network admins to have access to logs for their devices but don't want them to be able to make any changes. Even though they have root on their linux admin box, they can't alter the logs.

Here's my favorite guide if you want to read further: http://fullyautolinux.blogspot.com/2015/11/nfs-norootsquash-and-suid-basic-nfs.html


There are a couple of other things you can do. For example you can prevent root from being able to SSH to the device. This means that to become root, a user would need to access the device using a different account (e.g. an admin account you made), and then switch to the root user with a command like su.

A simple guide can be found here: https://mediatemple.net/community/products/dv/204643810/how-do-i-disable-ssh-login-for-the-root-user


Here is some doco from Redhat on how to limit the root account in enterprise environments: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-controlling_root_access


As discussed in other answers, you can also change the capabilities of the root account.

  • 1
    I am not sure why this answer was downvoted. Root can be limited or restricted by selinux and apparmor. Wayland also limits root access to a users graphical desktop. – Panther Feb 19 '19 at 23:23
  • Those are also good additions. Depending on distro there are a range of other tools. Hence posting the RHEL/CentOS link which has a number of PAM specific controls. – Crypteya Feb 19 '19 at 23:50
  • 1
    The question seems to be talking about capabilities in the sense of capabilities(7) man page, which are process attributes controlled by the kernel. Given this assumption, things like NFS root_squash and userspace things like SSH access control would be unrelated. Yes, it could have been specified more explicitly in the question. – telcoM Feb 20 '19 at 8:33
  • Yeah. Ideally the user would have specified what exactly they would have liked to prevent the root user from being able to do (or at least give one example). But people who find this thread in the future could benefit from any of the answers here. – Crypteya Feb 21 '19 at 0:57

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.