We're running systemd verson 219 on CentOS 7, inside an LXC container, and we're having trouble with capabilities. systemd appears to be dropping capabilities, contrary to the systemd.exec(5) man page. I have a C program and a shell script that effectively "grep '^Cap' /proc/$$/status" (the C program does it programmatically), and they both show reduced capabilities when run under systemd as opposed to run manually from the shell.

In the container:

# grep '^Cap' /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapAmb: 0000000000000000

and from the C program and shell script when run by systemd:

+ grep '^Cap' /proc/26977/status
CapInh:        0000000000000000
CapPrm:        0000001cfd6cffff
CapEff:        0000001cfd6cffff
CapBnd:        0000001cfd6cffff
CapAmb:        0000000000000000

The online docs imply that newer systemd should work better, but I can't find anything like release notes that talk about this. The service file contains nothing about capabilities; I've tried various configurations for it, they are either rejected (even the example in the man page, sometimes during daemon-reload, others when starting the service), drop all capabilities, or have no effect.

Using a newer systemd is too time- and energy-intensive to be practical at this point, conservative deployment being what it is.

EDIT: I believe that this is a "privileged" container, but your shell gets the same reduced capability set if you log in via the sshd running in the container, vs getting a full set by entering via lxc-attach. We would really like it if systemd had the full set of capabilities.

1 Answer 1


Found the problem: the capability that I was needing was being (explicitly!) dropped in the LXC config file being templated into place by saltstack. A little extra Jinja in the template, and the containers that need that capability now have it.

The difference between the capabilities was caused by our "enter the container" macro (a crutch emulating our previous container implementation) specifying "--elevated-privileges". Without it, we get the same reduced capabilities as any daemon (e.g., sshd) spawned inside the container.

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.