1 |
On Tue, 02 Aug 2011 10:51:22 -0400 |
2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
3 |
> > Would need a spec, along with a way of dealing with all the |
4 |
> > problems: what happens if the build fs supports caps but the |
5 |
> > install fs doesn't? What about if caps are supported on both but in |
6 |
> > different ways (tmpfs on some kernels)? Is it up to the PM to deal |
7 |
> > with that? How does the PM even know? |
8 |
> |
9 |
> That's exactly what I was thinking of for the PM. It would have to |
10 |
> autodetect all that. |
11 |
|
12 |
That's the problematic part... It's not quite "the PM just needs to |
13 |
come up with a cure for cancer", but it's decidedly non-trivial. |
14 |
|
15 |
> Eg. it could create a test file on each fs and |
16 |
> then do a getcap on it and if it fails, you have your answer. |
17 |
|
18 |
But it can and will be merging to multiple filesystems, some of which |
19 |
support caps and some of which don't. |
20 |
|
21 |
Maybe the answer is to have the PM do the merge, including caps, and if |
22 |
it detects that the caps setting failed then it should fall back to |
23 |
some kind of set*id bit (but which one?). But I'm not sure that setting |
24 |
caps that won't actually work will necessarily give a failure. |
25 |
|
26 |
Another possibility is to simply require that the PM preserve caps from |
27 |
the build fs to the root fs, and if it fails, to abort horribly (except |
28 |
we hate dying mid-merge, since it's impossible to clean up). Then it's |
29 |
the user's responsibility to turn off caps on their build fs if |
30 |
necessary. |
31 |
|
32 |
But neither of those are anywhere close to implementable without a lot |
33 |
of careful thought and planning... We need to *prove* that we're safe |
34 |
here, not guess that we're probably ok based upon a bit of testing. |
35 |
|
36 |
And we haven't even started talking about binaries yet... |
37 |
|
38 |
> I was thinking something even dirtier, something outside of the PMS |
39 |
> altogether, along the lines of what one does when converting to a |
40 |
> selinux system where one relabels the entire filesystem with rlpkg. |
41 |
> So no, not something via pkg_postinst(). |
42 |
|
43 |
Please don't. |
44 |
|
45 |
-- |
46 |
Ciaran McCreesh |