+++ This bug was initially created as a clone of Bug #646443 +++ Description of problem: Please remove setuid setup of files in your package with file capabilities. This is to satisfy the F15 feature. https://fedoraproject.org/wiki/Features/RemoveSETUID An example of how this was done for X is. %if 0%{?fedora} < 15 %define Xorgperms %attr(4711, root, root) %else %define Xorgperms %attr(0711,root,root) %caps(cap_sys_admin,cap_sys_rawio,cap_dac_override=pe) %endif
Can you offer a recipe that takes into account the possible setting of the no_file_caps kernel boot option, resetting setuidness, perhaps with a %postin scriptlet? Or is that option intended to be outlawed as of F15?
That is not really the goal. I don't believe we can remove all setuid apps, but I am hoping we can get most. su, sudo, ksu have to be setuid for the admin to be able to do his job. I do not see up removing the admin from the ability to chcon 4755 an app. But if we ship 25 packages in Fedora with setuid apps and we can get it down to < 10, that is an improvement.
I'm asking something a bit different - not whether you can get rid of all setuid programs, but whether you can adapt to a sysadmin wanting to not use capabilities in his filesystems.
Interesting. I guess if we did not recode applications to handle file capabilities, we could require them to be setuid.
rpm is supposed to fallback to making the app setuid.
I guess then the question would be whether or not we modify the apps to require the handling of setuid versus just having file capabilities. I don't believe newrole needs setuid capability if I have file capabilities for audit_write set.
If rpm handles the fallback correctly, then this update actually does nothing. IOW, if filesystem based capabilities is not present, then rpm should make the app setuid and therefore the same as F-14.
Considering that staprun does as-privileged-as-humanly-possible operations (loading kernel modules), IMHO let's leave the setuid flag in the face of the local sysadmin.