I have a docker container which runs perfectly fine in a kubernetes pod when privileged:true is set in the specification. But when I run the same docker container, by giving all the linux capabilities, it is failing. In both cases the capability bitmask for the processes are same and as follows:

SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000000004
SigCgt: 0000000000014002
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000

So, is there any difference between Running a process as root vs Running a process with all the capabilities.

Update : As pointed out by @ctrl-alt-delor, Setting privilege:true means that the container will have access to all devices on the host as well as same access to the host as processes running outside containers on the host

  • Technically shouldn't exist differences between running a process as root and running a process with full capabilities, or with CAP_SYS_ADMIN set. Since 2.2, Linux kernel stopped looking for UID == 0 on many places in favor of the capabilities system. But, your case should be a corner case. What operation(disk, net, cpu, fork...) are you doing that is creating the failure on your software?
    – user34720
    Feb 4, 2019 at 11:14
  • What container? Have you got a Dockerfile? Feb 4, 2019 at 11:21
  • @ctrl-alt-delor, It is actually a YAML spec for kubernetes DaemonSet. Feb 4, 2019 at 11:33
  • Whether or not root and all capabilities are exchangeable on the kernel, some software is still configured to behave differently towards root. Examples include passwd which does not ask for a password when initiated by root. Other software is frequently configured to give root special privileges. These which cannot privileges possibly be included in the Kernel's capabilities model. Feb 4, 2019 at 12:01
  • There is more than one YAML spec for kubernetes, which one? (My spy camera is not working at present, so you will have to tell us what you are trying to do). Feb 4, 2019 at 14:28

1 Answer 1


I think you are missing what is happening.

Privileged is not root. By default a container runs as root, but with few capabilities, and un-privileged.

To answer you question (in the title): Very little, just the user name, so files will be created as the user. However the user will have privileges to change user name. (except some buggy software that un-necessarily checks for root).

You will have to check the manual for what privileged does (I don't know, I do know that it is not the same as root, it is not the same as capabilities).

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices (see the documentation on cgroups devices).

When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with --privileged is available on the Docker Blog.

If you want to limit access to a specific device or devices you can use the --device flag. It allows you to specify one or more devices that will be accessible within the container.

You can also map individual files / directories, from host, with -v.

  • But why is the capability bitmask same for both cases? Feb 4, 2019 at 11:41
  • Because it is not different. Privileged is not root and it is not capabilities. Feb 4, 2019 at 14:29

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.