[lxc-users] setcap capabilities

[Serge Hallyn]

Quoting Mark Constable (markc at renta.net):
> On 14/02/16 03:20, Serge Hallyn wrote:
> >>but inside a container I get...
> >>
> >>~ /sbin/setcap cap_net_bind_service=+ep /usr/bin/caddy
> >>Failed to set capabilities on file `/usr/bin/caddy' (Invalid argument)
> >
> >If not in a user namespace, ... well it works for me, but you may
> >have to edit the files under /usr/share/lxc which get lxc.include'd
> >to make sure they're not dropping CAP_SETFCAP, and check your
> >apparmor/selinux policy. I'm not going more into detail on that until
> >we're sure you're not in a user namespace :)
> 
> Woops, sorry, xenial host with a xenial lxd 2.0.0~beta2 unprivileged
> container.
> 
> ***
> 
> This could be a separate list post but it may involve a similar solution.
> 
> The above is my main concern but this is also related and that is when
> I install certain packages (like courier-mta) it requires some suid
> capabilities to suid some symlink'd binaries and was failing inside
> this same unpriv container. The solution in this case was to set...
> 
> # for containers to allow suid exec
> echo 0 > /proc/sys/fs/protected_hardlinks
> 
> on the host but that is going to be awkward for folks who do not happen
> to know this "trick" meaning generally trying to install the courier-mta
> package on unpriv containers is going to fail in an ugly way that messes
> up package install/upgrades.
> 
> Any comment on how to make this easier to deal with?

I'm afraid not.  It's the exact case which the authors of the
protected_hardlinks mechanism wanted to protect against...