Re: [gentoo-dev] eclass for handling of file-based capabilities

[Brian Harring]

On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner <constanze@g.o> wrote:
>
> > On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> > > * some filesystems don't support xattrs at all, and the package
> > > manager needs to support installing to them, even if the user is
> > > building on a filesystem that does support it
> >
> > While GSoC I was not able to come up with a good fallback mechanism.
> > I'm going to give the new ideas some thought over the week and
> > hopefully come up with something good :).
>
> How about that:
> 1) src_install() installs a file, like in:
> 	/var/lib/gentoo/filecaps.d/${PF}
> specifying which caps have to applied to which files,
>
> 2) the eclass depends on an ebuild, installing a kind
> of 'filecaps-apply' tool, reading information from that file and trying
> to apply filecaps as necessary (and flipping setuid bits),
>
> 3) the eclass calls that tool in pkg_postinst() to apply the caps
> on the target filesystem.

Exactly what benefit is derived from trying to step outside the PM for 
this, and trying to hack up what the PM already set for permissions?

General rule of thumb, the more the PM knows the better things are 
going to be for people, and for long term compatibility.  If 
in doubt consider the improvements to user experience via 
revdep-rebuild functionality making it into the PM; PM can actually 
plan for rebuilds as it goes rather than potentially blowing up a 
later build (or telling the user "go run xyz"). Consider:

1) this tool will have to grow system/user configuration for 
overrides- something the PM could fold in easily enough into it's 
existing capbilities.  If in doubt consider FEATURES=suidctl .

2) has to be prefix aware, including understanding of deprived.  This 
can be done mind you, but like #1, the bits are already there at the 
PM level.

3) the information recorded there is ultimately redundant when/if a 
sane VDB format gets created; as is this info could just as easily be 
pushed in there as a new file per CPV in the existant VDB format.

4) this requires further OOB handling for ID databases- handling that 
could've been pushed into the PM itself (admittedly a weak point since 
ID is already mildly screwed up here, but no point in making it 
worse).

5) it opens up a window in every merge where setuid binaries are on 
disk, just prior to your proposed tool getting ran.  This is annoying 
to say the least, and if the system has disabled setuid in full it's a 
window where the binaries aren't actually usable.

6) it's slower than just having the PM do it.  Specifically, the PM is 
already transfering the content to disk, and fiddling it's bits- 
adjusting the files modes and setting capability is something it can 
do on creation (eliminating #5) rather than having to shell out to 
some script.  It's important to realize that the area this slows down 
is a critical section for parallelized binpkg merging- something the 
chrome-os folk have ran into.

6) shifting it to an external tool means the format used by the tool 
needs standardization (rather than just being standardized via PMS) to 
allow interop when inevitably a PM author goes to fold the 
functionality into the PM.

7) this tool, due to it being not part of the PM, the PM has to go out 
of it's way to protect the depgraph for- something it should already 
be doing for itself.  External, it's another hardcoded constant (or 
addition to system set) the PM has to watch for- w/in the pm, it ought 
to pay attention to it as is.


> This should help with all the issues mentioned, including binpkg
> support. Moreover, user could use the tool manually to restore/reset
> filecaps if they were lost or unapplied (e.g. due to incorrect kernel
> config).

Every issue you've raised is addressable at the PM level- generally 
speaking, done better at the PM level.

Basically... please fix the problem at the correct location.  
Capabilities, xattrs, etc, are not a temporary fad- they're 
increasingly a core requirement of a linux system (thus the PM that 
manages it).  The place for this functionality is in the PM- more 
importantly, trying to do it outside of it just makes a bigger mess 
for PM/format authors when inevtiably it has to be pulled in.

~harring