Default capability of cap_setfcap+i should be set on setcap

[Matthew Walker]

If I grant a user (via pam_cap) cap_setfcap+i, I would then expect them to be able to use setcap without sudo. setcap is not provided with any default file capabilities however, so either the user has to sudo, or I have to grant the setfcap capability to setcap with setcap.

In my mind, it would be reasonable to grant setfcap+i to setcap by default on installation.

[Serge Hallyn (serge-hallyn)]

Indeed it should be reasonable to do so. Note that there are cases, including unprivileged containers, where file capabilities cannot be set, so the packaging would have to gracefully handle (i.e. ignore) that failure rather than fail the package install.

[Serge Hallyn (serge-hallyn)]

Even unprivileged containers are now usable in containers with the right kernel, so this would be a good thing to add to the packaging.

I'm not sure when I'll have time, but assigning to myself so that I can more easily find it when I do.

[Balint Reczey (rbalint)]

@serge-hallyn I'm not sure why I got this bug assigned. :-)

[Andrew G. Morgan (morganlibcap)]

FWIW This used to be the default inside the libcap build tree, but the problems with the container defaults (eventually fixed with https://github.com/moby/moby/security/advisories/GHSA-2mm7-x5h6-5pvq
 ) changed my position on this:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=2b5f5635be6131d7e89b4c6244b29f32ebd163c1

[Dan Bungert (dbungert)]

Yes, this appears to be deliberate upstream behavior and I'm not sure we should revert that. Marking incomplete, if there is further info please share.

[Serge Hallyn (serge-hallyn)]

> FWIW This used to be the default inside the libcap build tree, but the
> problems with the container defaults (eventually fixed with
> https://github.com/moby/moby/security/advisories/GHSA-2mm7-x5h6-5pvq

Thanks for the links. For a moment I was worried that there was an
issue with containers in general, but I see, this is an implementation
issue with one container engine implementation.

And... they rated the importance low?

> ) changed my position on this:

> https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=2b5f5635be6131d7e89b4c6244b29f32ebd163c1

Hm. Maybe this is the wrong place to discuss this. I started this
comment intending to propose the opposite, but indeed if admins are
expected to use pam to set pI per username, then perhaps it is best if
they also have to set fI on each program they intend it to exist on,
since otherwise they may not *really* be sure what they are handing
the user...

Andrew, is it your intention to leave libcap's install without the fI?
If so then we should either (1) deliverately override Andrew's decision
during ubuntu packaging's postinst (which I don't think we should do),
or (2) mark this bug Invalid rather than Incomplete.

[Launchpad Janitor (janitor)]

[Expired for libcap2 (Ubuntu) because there has been no activity for 60 days.]