Bug 646493

Summary:	Replace SETUID in spec file with the correct file capabilities.
Product:	[Fedora] Fedora	Reporter:	Daniel Walsh <dwalsh>
Component:	systemtap	Assignee:	Frank Ch. Eigler <fche>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dsmith, dwalsh, fche, jistone, mgrepl, mjw, roland, sgrubb, wcohen
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	646443	Environment:
Last Closed:	2012-02-03 19:23:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	693731

Description Daniel Walsh 2010-10-25 13:42:01 UTC

+++ 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

Comment 1 Frank Ch. Eigler 2010-11-01 16:00:19 UTC

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 16:14:29 UTC

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 16:18:48 UTC

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 16:45:47 UTC

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 16:55:44 UTC

rpm is supposed to fallback to making the app setuid.

Comment 6 Daniel Walsh 2010-11-01 17:04:06 UTC

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 17:18:39 UTC

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 19:23:34 UTC

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.