setgid behavior change from CentOS 4 to CentOS 5

[mwa]

We have an application running under zdaemon with the "user=" option. The application reads files owned by another uid/gid. Under CentOS 4, adding the application's userid to the other group (with the files group readable) allowed the files to be read.

Under CentOS 5, the same application get's "permission denied" trying to read the file. It appears, the setgid/setuid sequence under CentOS file drops accessibility to suplementary groups.

By forcing the os.setgid(self.options.gid) to the required gid, read access to the file was regained.

It seems to me that the newer behavior is more secure. (I've tried tracing exactly when/where/why this behavior changed but with no luck.) I think an appropriate fix would be to add a "group =" option to zdaemon and setgid to that group if it is specified instead of the default gid of the "user =" option

[Colin Watson (cjwatson)]

The zdaemon project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zdaemon.