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:48:04 +0100
On 03:01 Sun 06 Mar     , Brian Harring wrote:
[snip]
Thanks for your feedback, your remarks were correct :). I updated the
eclass appropriately.

> I'd take a different approach here; this code basically assumes that 
> the PM knows of it- note the chmod -s.  The use flag protection you 
> tried adding, without some profile hacks, is user modifiable- meaning 
> users can flip it on even if the PM doesn't support it.
> 
> Or consider that the code above is purely doing it's thing during the 
> install phase, specifically against whatever filesystem is used for 
> building- while capabilities might be able to be set there, it's 
> possible the final merge location won't support it.  End result of 
> that is you'll get a setuid stripped binary merged to the 
> livefs lacking the caps- borkage.  Or consider the inverse- the 
> buildroot can't do capabilities, but the livefs could.  You get the 
> idea.
> 
> Instead, write the code so the PM has to export a marker in some 
> fashion to explicitly state "yes, I can do capabilities"- I'm 
> specifically suggestining checking for a callback function exposed to 
> the env.
> 
> If that function isn't there, then the PM can't do it- end of story.  
> If it is, the PM takes the args and will try to apply the 
> capabilities at the correct time- stripping setuid/setgid if it 
> succeeds.
> 
> Please go that route; and please do not stick "portage" into the 
> function name, something generic we can use for a later EAPI is 
> better.
> 
> Implementing it as I suggested has the nice side affect of not being 
> limited by PMS also, although it's an approach that still requires 
> planning for compatibility.
I'm currently in search of a good fallback mechanism respectivly a good
mechanism to deal with cap-setting in src_install. As I already said in
my mail to ciaran, I'm going to give the new ideas some thought :).

Cheers,
constanze


Replies:
Re: eclass for handling of file-based capabilities
-- Constanze Hausner
References:
eclass for handling of file-based capabilities
-- Constanze Hausner
Re: eclass for handling of file-based capabilities
-- Brian Harring
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:
Re: 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.