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: Sat, 16 Apr 2011 16:03:40
Message-Id: 20110416160443.GA22401@totoro.lan.kfr
In Reply to: Re: [gentoo-dev] eclass for handling of file-based capabilities by Constanze Hausner
1 > > I'd take a different approach here; this code basically assumes that
2 > > the PM knows of it- note the chmod -s. The use flag protection you
3 > > tried adding, without some profile hacks, is user modifiable- meaning
4 > > users can flip it on even if the PM doesn't support it.
5 > >
6 > > Or consider that the code above is purely doing it's thing during the
7 > > install phase, specifically against whatever filesystem is used for
8 > > building- while capabilities might be able to be set there, it's
9 > > possible the final merge location won't support it. End result of
10 > > that is you'll get a setuid stripped binary merged to the
11 > > livefs lacking the caps- borkage. Or consider the inverse- the
12 > > buildroot can't do capabilities, but the livefs could. You get the
13 > > idea.
14 > >
15 > > Instead, write the code so the PM has to export a marker in some
16 > > fashion to explicitly state "yes, I can do capabilities"- I'm
17 > > specifically suggestining checking for a callback function exposed to
18 > > the env.
19 > >
20 > > If that function isn't there, then the PM can't do it- end of story.
21 > > If it is, the PM takes the args and will try to apply the
22 > > capabilities at the correct time- stripping setuid/setgid if it
23 > > succeeds.
24 > >
25 > > Please go that route; and please do not stick "portage" into the
26 > > function name, something generic we can use for a later EAPI is
27 > > better.
28 > >
29 > > Implementing it as I suggested has the nice side affect of not being
30 > > limited by PMS also, although it's an approach that still requires
31 > > planning for compatibility.
32 > I'm currently in search of a good fallback mechanism respectivly a good
33 > mechanism to deal with cap-setting in src_install. As I already said in
34 > my mail to ciaran, I'm going to give the new ideas some thought :).
35
36 After some discussions with ferringb we came to the conclusion, that his
37 proposal to implement the cap-setting function in the PMS would be for
38 the best ;).
39
40 So for supporting filebased-caps, we need all PMS to provide a function
41 which:
42 - gets the final path and the caps to set, tries to set them and then
43 removes the suid-bit
44 - returns 0 or 1, indicating success or failure
45
46 If the user's setting doesn't allow caps, then the function is not
47 available.
48
49 Additionally we could also pass the fallback-filemode to the PMS, so it
50 could do the suid-setting itself, but this would be optional.
51
52 So PMS-Guys, please tell me what you think about that and if I can help
53 in any way. Filebased-caps could really help to have more secure systems
54 :).
55
56 btw, the eclass will be adapted, of course ;).
57
58 Cheers,
59 Constanze