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 |