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.