As stated in the linked mailinglist post: For supporting filebased-caps, we need all PMS to provide a function which: - gets the final path and the caps to set, tries to set them and then removes the suid-bit, if successful - returns 0 or 1, indicating success or failure If the user's setting doesn't allow caps, then the function is not available. Additionally we could also pass the fallback-filemode to the PMS, so it could do the suid-setting itself, but this would be optional. Reproducible: Always
I agree we should do this. I think it wouldn't be *that hard* to implement but it might be too late to include it in EAPI 7. One thing worth noting is that we may need to account for two separate problems: a. filesystem used for build not supporting capabilities, b. filesystem used for merge not supporting capabilities. One does not imply the other. In other words, the function might succeed when building package but the capabilities would be lost on install. The opposite is also possible -- not being able to set caps while building but being able to set it post-install. All that considered, I think it is important to have well-defined fallback here. In particular, the PM *must* be able to deal with missing capabilities after build with capabilities succeeded (and when using binpkg built with caps). For extra points, being able to 'remember' capabilities when filesystem can't store them during build would also be useful. I'm not sure if 'mode' is the only thing fallback needs to be concerned about. In some cases ownership may also be relevant. We should research existing uses of fcaps.eclass for this, I guess.
(CC-ing fcaps.eclass maintainers)
PMS currently requires selinux contexts, stored as xattrs (security.selinux), to be preserved from D -> ROOT I don't think it's a leap of imagination to conclude that it is just as easy to require capabilities, stored as xattrs (security.capability) to be preserved from D -> ROOT as well. If the function succeeds at build but fails at merge due to failure in the underlying filesystem, then this is already a violation of PMS because of selinux. We should simply document the requirement for capabilities as well.
