Bug 8524 - Suid bit lost if file's group does not exist.
Suid bit lost if file's group does not exist.
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-17 02:31 EST by Pekka Savola
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-17 10:57:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pekka Savola 2000-01-17 02:31:18 EST
Our Redhat installations use a modified version of RedHat/base/comps to
accommodate new RPM packages we want to have installed.

One of these has a file the permissions and owners of which are 4710
root:ourgroup.  Ourgroup is a group that will be created later in the
installation/fixing process.  The reason we can't do it in RPM is because
a specific GID is required and xfs usually kidnaps it; all the changes will
be made after the normal installation.

In 6.1 installs (we only do ftp text installs, btw), suid bit of that
file is lost.  In 6.0, it worked fine.  I believe there might be some
check to see if gid/uid's match which removed the suid bit if something
seems to be wrong.

Isn't this overcautious?  It's good that you can't cheat yourself a root
SUID bits using weird UID's in RPMs, but having group changed to 'root'
when the file is setUID root (and not setGID ourgroup) does no harm -- it
only tightens the security (as ourgroup users can't use the file anymore)
-- and wouldn't seem to warrant the removal of suid bit.

The same would go to a file which is setgid group, but the owner of which
changes (but the group stays the same).

Installing the RPM with rpm-3.0.3 changed the group from ourgroup to root
and retained the suid bit, so I think this is an installer feature.
Comment 1 Erik Troan 2000-02-17 10:57:59 EST
This is important behavior.

Given the security concerns around setuid programs, we don't want to do anything
that changes their behavior in unexpected ways. If the program is not in the
proper group, it could cause failures that aren't handled properly, and I
don't want RPM to be responsible.

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