Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Constanze Hausner <constanze@g.o>
Subject: Re: eclass for handling of file-based capabilities
Date: Sun, 6 Mar 2011 17:34:29 +0100
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


Replies:
Re: eclass for handling of file-based capabilities
-- Brian Harring
References:
eclass for handling of file-based capabilities
-- Constanze Hausner
Re: eclass for handling of file-based capabilities
-- Ciaran McCreesh
Re: eclass for handling of file-based capabilities
-- Constanze Hausner
Re: eclass for handling of file-based capabilities
-- Ciaran McCreesh
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: eclass for handling of file-based capabilities
Next by thread:
Re: eclass for handling of file-based capabilities
Previous by date:
bugs.g.o - Bugzilla4 testing
Next by date:
Re: bugs.g.o - Bugzilla4 testing


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.