1 |
On Tue, 02 Aug 2011 10:51:22 -0400 |
2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
3 |
|
4 |
> On 08/02/2011 10:31 AM, Ciaran McCreesh wrote: |
5 |
> > On Tue, 02 Aug 2011 10:28:58 -0400 |
6 |
> > "Anthony G. Basile" <blueness@g.o> wrote: |
7 |
> >> I prefer capsetting in the PMS itself, with a nice clean function |
8 |
> >> which auto detects all the necessary conditions and transparently |
9 |
> >> preserves caps, as you suggest. Maybe this can be in EAPI=5. |
10 |
> > Would need a spec, along with a way of dealing with all the |
11 |
> > problems: what happens if the build fs supports caps but the |
12 |
> > install fs doesn't? What about if caps are supported on both but in |
13 |
> > different ways (tmpfs on some kernels)? Is it up to the PM to deal |
14 |
> > with that? How does the PM even know? |
15 |
> > |
16 |
> |
17 |
> That's exactly what I was thinking of for the PM. It would have to |
18 |
> autodetect all that. Eg. it could create a test file on each fs and |
19 |
> then do a getcap on it and if it fails, you have your answer. If |
20 |
> necessary and it exists, it could look at /proc/config. I think it's |
21 |
> doable. |
22 |
|
23 |
Just let the capsetting function store all details internally when |
24 |
called. I don't think it's really important whether build fs capsetting |
25 |
succeeds. So, it's like: |
26 |
|
27 |
1) capset on buildfs, store details internally; |
28 |
2) move to livefs; |
29 |
3) [optionally] getcap on livefs, done if set; |
30 |
4) capset on livefs; |
31 |
5) getcap on livefs, done if set; |
32 |
6) fallback to set?id (using info from stored capsetting function call) |
33 |
if necessary. |
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |