On Tuesday, November 09, 2010 10:34:22 Pádraig Brady wrote:
On 09/11/10 14:56, Mike Frysinger wrote:
On Sunday, November 07, 2010 08:57:22 Yaron Sheffer wrote:
I still don't see the logic of not including capabilities in the
"install" feature set. We could use chmod and chown separately, too. But
still, setting owner/group and mode are a core functionality of this
utility. Similarly, if we think that POSIX capabilities are important
(see e.g. http://fedoraproject.org/wiki/Features/RemoveSETUID), we
should make their use as easy and natural as possible. For me that means
at the minimum support in install, tar (and derived packaging tools) and
possibly ls.
FWIW, it'd make my life easier as a distro maintainer as i wouldnt need
to force `setcap` on everyone ...
By forcing `setcap` on everyone, do you mean as a
build time package dependency, or does gentoo&/or dpkg
not support capabilities thus requiring it as an install time dep?
install-time pm dep. so when installing a pre-compiled binary package, we
need some way of saving/restoring the caps since tar doesnt support it. i
guess one alternative would be for the pm itself to integrate the save/restore
functionality. although atm that too would fall back to using `setcap` ...
If a package needs capabilities, is this dep really an issue?
i'm thinking of cases like `ping`. i want to set caps on it in the fs, but
ping itself doesnt utilize libcap at runtime to change things on the fly.
Could you expand on the failure modes you would expect.
I presume if one asks for capabilities we should error if they weren't set.
Would we need to verify like setcap -v?
i'm not familiar with the libcap API. i would expect that attempts to set
caps that fail would bubble up as exit() errors, but that would be based on
the presumption of the libcap API returning an error inline.
if the libcap API itself doesnt do error checking but requires an extended
write/read/verify cycle, a -v option like setcap would probably make sense.
-mike