LXC Capabilities

[lweidig]

I am hoping to rely on the wisdom of the group to help with an item we are having issues with since upgrading our OpenVZ container to LXC on a 4.0 system. One of them requires capabilities applied to a binary so that it is able to open ports 80 / 443 for web services but still run as an unprivileged account. The specific command issued during the install is:

setcap "CAP_NET_BIND_SERVICE,CAP_NET_BROADCAST+ep" "/usr/local/bin/myprogram"

It seems that the capabilities are setup in the /usr/share/lxc/config folder through a number of conf files. I would prefer to only allow this in the single container needing it and wonder how to go about overriding this for it only. Any input would be appreciated. Thanks!

 

[sigxcpu]

Looks like "lxc.cap.keep" will help you here (same syntax as lxc.cap.drop). I don't know if that is implemented in Proxmox (i.e. copied when the .conf file is translated), though.

LE: it is copied, it seems.

 

[lweidig]

Looks like "lxc.cap.keep" will help you here (same syntax as lxc.cap.drop). I don't know if that is implemented in Proxmox (i.e. copied when the .conf file is translated), though.

LE: it is copied, it seems.

Tried that, but this only ends up with the container not starting and the message:

Simultaneously requested dropping and keeping caps

being logged. I am sure it has to do with the configurations in /usr/share/lxc, just unsure at this point how to resolve this problem in a way that does not alter Proxmox for EVERY container.

 

[sigxcpu]

I've tried that myself and got the same message. So it seems that keep/drop are mutually exclusive (I don't understand why, because their whole purpose is to fine tune containers privileges).

 

[lweidig]

Ok, I feel a bit silly but want to post the solution to this problem for me. First I had to add the following line to my configuration file found under /etc/pve/lxc/nnn.conf where nnn is the VMID:

lxc.aa_profile = unconfined

I have not confirmed that was 100% necessary but really do not want to stop the machine to find out. After that I simply had to rerun the command inside the container:

setcap "CAP_NET_BIND_SERVICE,CAP_NET_BROADCAST+ep" "/usr/local/bin/myprogram"

Apparently capabilities are not transferred during backup / restore.

 

[wbumiller]

Correct. The backup files (just like templates) are tar archives, which by default don't include extended attributes (which is how capabilities are stored). There also seems to be some disagreement as to how they're supposed to be stored in archives.
GNU tar generated archives error with bsdtar and vice versa when they try to include such attributes. Apparently GNU tar includes raw binary for xattrs which goes against the pax specification (see the links below).

Btw you don't need to play around with lxc.cap.keep for these particular capabilities as they're part of the default set.
Without any such configuration:

container # grep CapPrm /proc/self/status
CapPrm: 0000003c7d6cffff
container # capsh --decode=0000003c7d6cffff
0x0000003c7d6cffff=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_chroot,cap_sys_ptrace,cap_sys_admin,cap_sys_boot,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_syslog,cap_wake_alarm,cap_block_suspend,37

Links:
http://lists.gnu.org/archive/html/bug-tar/2013-12/msg00012.html
http://lists.gnu.org/archive/html/bug-tar/2013-12/msg00016.html

 

[wbumiller]

In case you're interested: https://git.proxmox.com/?p=pve-container.git;a=commit;h=fc4e132e1a718a31dd7a098375ea3c24211fcebb
They should be preserved across dumps with the next package updates.

 

[lweidig]

In case you're interested: https://git.proxmox.com/?p=pve-container.git;a=commit;h=fc4e132e1a718a31dd7a098375ea3c24211fcebb
They should be preserved across dumps with the next package updates.

Thank you for making that enhancement, appreciate it!

 

[wbumiller]

Note that unfortunately only newly created dumps will contain the necessary information.

 

[lweidig]

Aww, come on. Read through all of the old dumps and inject them into the backups

Just kidding of course, understood that it will be going forward. Still a big thanks for this!