On Tue, 02 Aug 2011 10:51:22 -0400 "Anthony G. Basile" <bluen...@gentoo.org> wrote: > > Would need a spec, along with a way of dealing with all the > > problems: what happens if the build fs supports caps but the > > install fs doesn't? What about if caps are supported on both but in > > different ways (tmpfs on some kernels)? Is it up to the PM to deal > > with that? How does the PM even know? > > That's exactly what I was thinking of for the PM. It would have to > autodetect all that.
That's the problematic part... It's not quite "the PM just needs to come up with a cure for cancer", but it's decidedly non-trivial. > Eg. it could create a test file on each fs and > then do a getcap on it and if it fails, you have your answer. But it can and will be merging to multiple filesystems, some of which support caps and some of which don't. Maybe the answer is to have the PM do the merge, including caps, and if it detects that the caps setting failed then it should fall back to some kind of set*id bit (but which one?). But I'm not sure that setting caps that won't actually work will necessarily give a failure. Another possibility is to simply require that the PM preserve caps from the build fs to the root fs, and if it fails, to abort horribly (except we hate dying mid-merge, since it's impossible to clean up). Then it's the user's responsibility to turn off caps on their build fs if necessary. But neither of those are anywhere close to implementable without a lot of careful thought and planning... We need to *prove* that we're safe here, not guess that we're probably ok based upon a bit of testing. And we haven't even started talking about binaries yet... > I was thinking something even dirtier, something outside of the PMS > altogether, along the lines of what one does when converting to a > selinux system where one relabels the entire filesystem with rlpkg. > So no, not something via pkg_postinst(). Please don't. -- Ciaran McCreesh
signature.asc
Description: PGP signature
