> > 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 :).

After some discussions with ferringb we came to the conclusion, that his
proposal to implement the cap-setting function in the PMS would be for
the best ;).

So for supporting filebased-caps, we need all PMS to provide a function
which: 
- gets the final path and the caps to set, tries to set them and then
removes the suid-bit
- returns 0 or 1, indicating success or failure

If the user's setting doesn't allow caps, then the function is not
available.

Additionally we could also pass the fallback-filemode to the PMS, so it
could do the suid-setting itself, but this would be optional.

So PMS-Guys, please tell me what you think about that and if I can help
in any way. Filebased-caps could really help to have more secure systems
:).

btw, the eclass will be adapted, of course ;).

Cheers,
Constanze