setgid behavior change from CentOS 4 to CentOS 5

Bug #769209 reported by mwa on 2011-04-22
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
zdaemon
Invalid
Undecided
Unassigned

Bug Description

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) wrote :

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.

Changed in zdaemon:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers