Support for Initializing the Supplementary Group List.

[Malcolm Purvis]

>>>>> "Ben" == Ben Finney <ben+python at benfinney.id.au> writes:

Thanks for looking at the bundle.

>> The test runs fine on the command line but fails under the daemon
>> because 'sudo' is a supplementary group, which hasn't been
>> initialized.

Ben> Hmm. And it succeeds on the command line because of special
Ben> behaviour of ‘sudo’? Or because a login shell is started?

It succeeds because of the latter.  The command line is either a login
shell or started via a session manager.  In both cases, initgroups() is
called as part of the login sequence.

>> The bundle adds a new keyword, initgroups, which if True, calls
>> os.initgroups(), which will initialize the supplementary group list
>> to all of the entries in /etc/groups that contain the uid.

Ben> Is there a reason to make this optional? Why would this not be
Ben> desired for all daemons?

I made it optional because it's a change in behaviour and I didn't want
to break backward compatibility.

I'm not sure about whether it should be made compulsory.  Daemons can
run as root, and at present setting the uid and gid are optional, so
requiring initgroups could introduce unexpected behaviour.

Ben> When a programmer wants to over-ride the behaviour, what
Ben> information are they likely to want to provide: a simple “dno't do
Ben> it”, or a list of supplementary groups to set, or something else?

Generally you'd want to set all of the supplementary groups or none at
all.  There is an underlying system call, setgroups(2) which can be used
to set an arbitrary collection of groups, but initgroups() provides the
common behaviour.

Another possibility is to have another parameter, "run_as=<username>"
which would fetch the uid, gid and supplementary group list from the
password file.

Malcolm

-- 
		Malcolm Purvis <m.purvis at marathon-targets.com>