Bug 88242 - RPM doesn't attempt to change group ownership when not running as root
RPM doesn't attempt to change group ownership when not running as root
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-07 23:59 EDT by Matthew Braithwaite
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-25 13:34:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Matthew Braithwaite 2003-04-07 23:59:11 EDT
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 01:01:46 EDT
Created attachment 90990 [details]
patch
Comment 2 Jeff Johnson 2003-06-25 13:34:13 EDT
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.