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

And a process that's run by the root user has all of the capabilities available, but can such a process have some of its capabilities removed, either manually or automatically in certain situations?

4 Answers 4


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, 2019 at 5:40
  • 1
    @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, 2019 at 8:47

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, 2019 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, 2019 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, 2019 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, 2019 at 0:57

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)


I am adding information to @ilkkachu answer.
It seems that the capabilities of the process determines if the user is privileged or not.

For example, let's remove all the capabilities except one (cap_checkpoint_restore):

capsh --drop=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf -- -c 'sleep 10000'

We can see that this user has only one capability cap_checkpoint_restore, even when the user is root:

#  ps aux | grep sleep
root     2309662  0.0  0.0   5768  1008 pts/5    S+   07:21   0:00 sleep 10000

# cat /proc/2309662/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000010000000000
CapEff: 0000010000000000
CapBnd: 0000010000000000
CapAmb: 0000000000000000

# capsh --decode=0000010000000000

You must log in to answer this question.

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