Support for Initializing the Supplementary Group List.

Ben Finney ben+python at benfinney.id.au
Thu Jul 17 05:56:15 UTC 2014


On 23-May-2014, Malcolm Purvis wrote:
> The attached bzr bundle adds support for initializing the process's
> supplementary group list if required.

Thank you for this patch 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.

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

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

Here is an article describing a sequence of steps to “lock down” a
daemon <URL:http://www.palecrow.com/chroot-jail-paper.html>, including
a call to the C library function ‘initgroups()’ as you describe.

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

If optional, should the default be to call ‘initgroups()’?

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

-- 
 \      “An expert is a man who has made all the mistakes which can be |
  `\                         made in a very narrow field.” —Niels Bohr |
_o__)                                                                  |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-daemon-devel/attachments/20140717/1dbc52e6/attachment.sig>


More information about the python-daemon-devel mailing list