Bug 88242 - RPM doesn't attempt to change group ownership when not running as root
Summary: RPM doesn't attempt to change group ownership when not running as root
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-08 03:59 UTC by Matthew Braithwaite
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-25 17:34:13 UTC
Embargoed:


Attachments (Terms of Use)
patch (1.21 KB, patch)
2003-04-08 05:01 UTC, Matthew Braithwaite
no flags Details | Diff

Description Matthew Braithwaite 2003-04-08 03:59:11 UTC
When rpm is run as not as root, it doesn't attempt to chown(2) any of the files
it installs.  I suspect that the origin of this behavior is to permit rpm to be
run as non-root without noisy chown failures.  But I think a better solution is
to attempt the chown and fail silently if the chown fails with EPERM.

Why: in our environment we make extensive use of RPM deployment by non-root
users.  We therefore make much use of group memberships as a substitute for the
time-honored practice of running everything as root.  We quickly learned that
one could not specify group ownership in the %files section of an RPM spec file.
 Instead, one has to do an explicit chgrp in %post, which is confusing to
newcomers and hard to audit.

Hence my suggestion.  If it meets with your approval I'm can supply either of
two patches:

  1. When non-root, don't attempt change ownership, and attempt change group
  if and only if group is one of the groups of the user running RPM.

  2. When non-root, attept change ownership and change group, but do not 
  complain on failure unless errno is something other than EPERM.

(The second approach seems cleaner to me.)  Either of these changes allows RPM
to continue behaving as it does now, namely, never complaining that it has
insufficient permission to alter the owner or group of the files it installs.

Please let me know what you think, & thanks for your consideration.

Comment 1 Matthew Braithwaite 2003-04-08 05:01:46 UTC
Created attachment 90990 [details]
patch

Comment 2 Jeff Johnson 2003-06-25 17:34:13 UTC
Patch looks OK, but ignoring EPERM assumes that rpm
has a deep and complete understanding of all cases
where EPERM is returned, not true for, say, chattr.

I can add the patch if you rework to test a configuration
macro, where the default "normal" behavior is to not ignore
EPERM.


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