Gentoo Archives: gentoo-dev

From: Constanze Hausner <constanze@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] eclass for handling of file-based capabilities
Date: Sun, 06 Mar 2011 16:33:43
Message-Id: 20110306163428.GB14815@totoro.lan.kfr
In Reply to: Re: [gentoo-dev] eclass for handling of file-based capabilities by Ciaran McCreesh
On 17:44 Sat 05 Mar     , Ciaran McCreesh wrote:
> On Sat, 5 Mar 2011 18:41:46 +0100 > Constanze Hausner <constanze@g.o> wrote: > > > You're requiring special package manager behaviour if that flag is > > > set? > > > > I'm requiring, that the package manager preserves the xattrs, when > > stripping the binary and when moving it from the sandbox to the > > live-fs. > > Currently we've got wording in PMS forbidding anything from relying > upon xattrs being preserved correctly, since that's what Portage did > when we wrote it. So if you're looking to change that, you'll need to > EAPI control it.
Yes, there would be the need for a new EAPI, if the caps should be set from src_install and therefore need to be preserved by the PMS. As long as there is no such garantee one could use the eclass to set the caps from pkg_postinst. I know it's really ugly, but it would be a start. Otherwise we will never be able to use caps.
> But it's not as simple as just requiring attributes to be preserved in > future EAPIs, since: > > * some xattrs are fs specific > > * some xattrs (selinux?) can't be copied
I said something different than I thought, sorry. I only thought of the caps and not other kinds of xattr, as I only require caps to be preserved. Caps do either work on a fs or they don't and they can be copied.
> * 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
That's true, additionaly even if the fs is able to support xattr, there are kernel options, which need to be set. I agree with you, that that's a huge problem. We need to have a good fallback mechanism. Zac metioned that we could have three modes for movefile: 1) no caps 2) tolerant mode, which does not fail if caps could not be copied 3) strict mode, which fails if caps can't be copied ferringb metioned some kind of marker with which one can indicate xattr support. 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 :).
> * tar and xattrs is a massive problem, so how do binaries work?
tar can be patched to support xattrs. If we want to use caps, we will have to apply those patches too. (iirc Fedora already uses such patches).
> I think it'd help if you provided a description of how all the above > (plus the other issues that I've forgotten about) can be handled.
I hope I cleared things up at least a bit :). Cheers, constanze


Subject Author
Re: [gentoo-dev] eclass for handling of file-based capabilities Brian Harring <ferringb@×××××.com>
Re: [gentoo-dev] eclass for handling of file-based capabilities "Michał Górny" <mgorny@g.o>