Some advanced things that you might want to do within a container, such as Docker-in-Docker (DinD), NTP, mounting loopback devices, and many others, will require higher privileges than the ones given to the root user of the container by default. As such, additional privileges need to be allowed for the container to run without issues, so for that use case, Docker has a very simple but extremely broad privileged mode that adds the complete host's capabilities to the container. To use this mode, just append --privileged to the docker run command:

$ # Run an NTP daemon without the extra privileges and see what happens
$ docker run -it 
             --rm 
             cguenther/ntpd

ntpd: can't set priority: Permission denied
reset adjtime failed: Operation not permitted
creating new /var/db/ntpd.drift
adjtimex failed: Operation not permitted
adjtimex adjusted frequency by 0.000000ppm
ntp engine ready
reply from 38.229.71.1: offset -2.312472 delay 0.023870, next query 8s
settimeofday: Operation not permitted
reply from 198.206.133.14: offset -2.312562 delay 0.032579, next query 8s
reply from 96.244.96.19: offset -2.302669 delay 0.035253, next query 9s
reply from 66.228.42.59: offset -2.302408 delay 0.035170, next query 7s
^C

$ And now with our new privileged mode
$ docker run -it 
             --rm 
             --privileged 
             cguenther/ntpd

creating new /var/db/ntpd.drift
adjtimex adjusted frequency by 0.000000ppm
ntp engine ready
^C

As you can see, adding this flag removes all errors from the output as we can now change the system time.

With the functionality of this mode explained, we can now talk about why ideally, if possible, you should never use the privileged mode. By default, the privileged mode allows practically full access to most of the host's systems and is not granular enough to make sense in most circumstances, so after you figure out that your container needs additional privileges, you should selectively add them with --cap-add instead. These flags are standard Linux capability identifiers that you can find in places such as http://man7.org/linux/man-pages/man7/capabilities.7.html and allow fine-tuning to the level of access you desire. If we now convert our previous NTP daemon example into this new style, it should look a bit more like this:

$ # Sanity check
$ docker run -it 
             --rm 
             cguenther/ntpd

ntpd: can't set priority: Permission denied
<snip>
settimeofday: Operation not permitted
<snip>
^C

$ # Now with the added SYS_TIME capability
$ docker run -it 
             --rm 
             --cap-add SYS_TIME 
             cguenther/ntpd

ntpd: can't set priority: Permission denied
creating new /var/db/ntpd.drift
adjtimex adjusted frequency by 0.000000ppm
ntp engine ready
reply from 204.9.54.119: offset 15.805277 delay 0.023080, next query 5s
set local clock to Mon Oct  2 06:05:47 UTC 2017 (offset 15.805277s)
reply from 38.229.71.1: offset 0.005709 delay 31.617842, next query 9s
^C

If you noticed, we still have an error visible due to another missing capability, but the settimeofday error is gone, which is the most important problem that we needed to fix for this container to run.

Interestingly enough, we can also drop capabilities from our container that are not being used with --cap-drop if we want to increase security. For this flag, there is also a special keyword, ALL, that can be used to drop all available privileges. If we use this to fully lock down our NTP container but have everything working, let us see what that will look like:

docker run -it 
           --rm 
           --cap-drop ALL 
           --cap-add SYS_TIME 
           --cap-add SYS_CHROOT 
           --cap-add SETUID 
           --cap-add SETGID 
           --cap-add SYS_NICE 
           cguenther/ntpd

creating new /var/db/ntpd.drift
adjtimex adjusted frequency by 0.000000ppm
ntp engine ready
reply from 216.229.0.49: offset 14.738336 delay 1.993620, next query 8s
set local clock to Mon Oct  2 06:16:09 UTC 2017 (offset 14.738336s)
reply from 216.6.2.70: offset 0.523095 delay 30.422572, next query 6s
^C

Here, we have removed all capabilities first and then added back the few that are really needed to run the container, and as you can see, things are working just fine. In your own deployments, I would strongly suggest that if you have spare development capacity or are security-oriented, take some time to lock your running containers in this manner as they will be much more secure and you will be much more sure that the container is running with the principle of least privilege.