Re: [coreutils] [patch] Re: Install enhancement request: capabilities
On Wednesday, November 10, 2010 07:00:51 Pádraig Brady wrote: > Ideally the package archive format should > support capabilities if they're needed, > and tar et. al. should support the attributes > if they're important. yes, but tar doesnt support it today > From a package maint point of view, > if you're changing a package to use capabilities, > then adding the dep is a minor inconvenience. that isnt the case. in the oft-quoted "ping" case, the package itself isnt changing in any way. the file permissions are simply being changed from granting it set*id to granting it the one explicit network capability it requires. > 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. except that coreutils is required on a system which means `install` is required. `setcap` is not. -mike signature.asc Description: This is a digitally signed message part.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Libcap, specifically cap_set_file() returns an error when it cannot set capabilities on a file. In the proposed patch, this is indeed bubbled up as an exit error. Thanks, Yaron On 11/10/2010 01:49 AM, 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. 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
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
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.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
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 signature.asc Description: This is a digitally signed message part.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
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 ... >> -mike > > Your experience in these matters certainly sways things. > I'd like to understand fully though before proceeding. > > 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? > > If a package needs capabilities, is this dep really an issue? > > 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 don't see any advantage to doing this via an install option. However, there *are* good arguments for making it easy to set capabilities via upstream Makefile.am rules. To that end, you can define an AC_SUBST'd variable, SETCAP, to "setcap" or say, "true" or "missing...", depending on whether a configure-time test decides there is a capable setcap program. Choose "true" if you want to ignore its absence. Then use $(SETCAP) in the installation rules. You could probably manage the existence check in the Makefile rule itself, rather than in a configure check. If install provided this option, you could arrange to do the same thing via this: install $(CAP_OPTIONS_FOR_FOO) $(other_install_options) foo install $(CAP_OPTIONS_FOR_BAR) $(other_install_options) bar but that isn't as clean.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
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 ... > -mike Your experience in these matters certainly sways things. I'd like to understand fully though before proceeding. 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? If a package needs capabilities, is this dep really an issue? 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? cheers, Pádraig.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
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 ... -mike signature.asc Description: This is a digitally signed message part.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Hi Jim, Pádraig, 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. Thanks, Yaron On 11/04/2010 03:22 PM, Jim Meyering wrote: Yaron Sheffer wrote: it's somewhat cleaner to have all the security-critical settings in one place: owner, group, permissions, capabilities (and grep for "-P" or "--capabilities"...). Plus you can rely on "install" to always be there, which I don't think is true for "setcap". Thanks for the patch. However, since that's the only benefit I see (setcap may not be installed), I'm 60:40 against. If you find some other install program with this feature, that would strengthen the case for adding the option here.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Yaron Sheffer wrote: > it's somewhat cleaner to have all the security-critical settings in > one place: owner, group, permissions, capabilities (and grep for "-P" > or "--capabilities"...). Plus you can rely on "install" to always be > there, which I don't think is true for "setcap". Thanks for the patch. However, since that's the only benefit I see (setcap may not be installed), I'm 60:40 against. If you find some other install program with this feature, that would strengthen the case for adding the option here.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Hi Pádraig, it's somewhat cleaner to have all the security-critical settings in one place: owner, group, permissions, capabilities (and grep for "-P" or "--capabilities"...). Plus you can rely on "install" to always be there, which I don't think is true for "setcap". Thanks, Yaron On 11/04/2010 02:55 PM, Pádraig Brady wrote: On 04/11/10 11:08, Pádraig Brady wrote: Thanks for the patch! I think the feature is worth it. Currently install does not preserve xattrs and so looses any previous capabilities associated with a file. In any case, capabilities don't need to be implemented using xattrs, and might not be on tmpfs on Linux for example when support is eventually added there. One tricky thing I noticed with capabilities, is that one needs to do after setting any ownership, which you do correctly in the patch. On the other hand one can always just call `setcap` after `install` for the few files that require it. Having `install` support it means you don't need a separate setcap util, but it also means that one can't just grep for "setcap" in a bunch of rpms for example to see what capabilities are set on the system. Also using the `setcap` util is slightly more flexible in failure modes (optionally failing if all/some/none are set) So I'm back to 55:45 against this one. cheers, Pádraig.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
On 04/11/10 11:08, Pádraig Brady wrote: > Thanks for the patch! > I think the feature is worth it. > > Currently install does not preserve xattrs > and so looses any previous capabilities > associated with a file. > > In any case, capabilities don't need to be implemented > using xattrs, and might not be on tmpfs on Linux > for example when support is eventually added there. > > One tricky thing I noticed with capabilities, > is that one needs to do after setting any ownership, > which you do correctly in the patch. On the other hand one can always just call `setcap` after `install` for the few files that require it. Having `install` support it means you don't need a separate setcap util, but it also means that one can't just grep for "setcap" in a bunch of rpms for example to see what capabilities are set on the system. Also using the `setcap` util is slightly more flexible in failure modes (optionally failing if all/some/none are set) So I'm back to 55:45 against this one. cheers, Pádraig.
Re: [coreutils] [patch] Re: Install enhancement request: capabilities
Thanks for the patch! I think the feature is worth it. Currently install does not preserve xattrs and so looses any previous capabilities associated with a file. In any case, capabilities don't need to be implemented using xattrs, and might not be on tmpfs on Linux for example when support is eventually added there. One tricky thing I noticed with capabilities, is that one needs to do after setting any ownership, which you do correctly in the patch. cheers, Pádraig.
