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