Bug 646493 - Replace SETUID in spec file with the correct file capabilities.
Replace SETUID in spec file with the correct file capabilities.
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Frank Ch. Eigler
Fedora Extras Quality Assurance
Depends On:
Blocks: removesuid16
  Show dependency treegraph
Reported: 2010-10-25 09:42 EDT by Daniel Walsh
Modified: 2012-02-03 14:23 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 646443
Last Closed: 2012-02-03 14:23:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2010-10-25 09:42:01 EDT
+++ 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.


An example of how this was done for X is.

%if 0%{?fedora} < 15
%define Xorgperms %attr(4711, root, root)
%define Xorgperms %attr(0711,root,root) %caps(cap_sys_admin,cap_sys_rawio,cap_dac_override=pe)
Comment 1 Frank Ch. Eigler 2010-11-01 12:00:19 EDT
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?
Comment 2 Daniel Walsh 2010-11-01 12:14:29 EDT
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.
Comment 3 Frank Ch. Eigler 2010-11-01 12:18:48 EDT
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.
Comment 4 Daniel Walsh 2010-11-01 12:45:47 EDT
Interesting.  I guess if we did not recode applications to handle file capabilities, we could require them to be setuid.
Comment 5 Steve Grubb 2010-11-01 12:55:44 EDT
rpm is supposed to fallback to making the app setuid.
Comment 6 Daniel Walsh 2010-11-01 13:04:06 EDT
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.
Comment 7 Steve Grubb 2010-11-01 13:18:39 EDT
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.
Comment 8 Frank Ch. Eigler 2012-02-03 14:23:34 EST
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.

Note You need to log in before you can comment on or make changes to this bug.