Re: [coreutils] [patch] Re: Install enhancement request: capabilities

[Pádraig Brady]

On 09/11/10 23:49, Mike Frysinger wrote:
> 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.

Thanks for the clarification.
Ideally the package archive format should
support capabilities if they're needed,
and tar et. al. should support the attributes
if they're important.

>From a package maint point of view,
if you're changing a package to use capabilities,
then adding the dep is a minor inconvenience.
Also one could take the view that adding a separate
`setcap` call might be easier to maintain than
messing with existing `install` commands.
Also `install` might not have even been used.
Also at a stretch, one could argue that having a dep
on the binary package, might be useful to allow one to
query which packages on the system require capabilties.

So this is still marginal in my mind.

>> 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

I think setcap -v is a separate convenience actually
and not related to the API, so bubbling up the boolean is fine.

cheers,
Pádraig.