coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Frysinger
Subject: Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Date: Tue, 9 Nov 2010 18:49:44 -0500
User-agent: KMail/1.13.5 (Linux/2.6.36; KDE/4.5.2; x86_64; ; )

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

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]