Bug#773291: Unable to inherit groups from user
control: forwarded -1 https://lists.alioth.debian.org/pipermail/python-daemon-devel/2014-July/54.html control: retitle -1 python-daemon: Should allow to set supplementary groups for daemon process control: tags -1 - moreinfo + confirmed On 17-Dec-2014, martin f krafft wrote: > also sprach Ben Finney [2014-12-17 02:13 +0100]: > > Ah, maybe you're thinking the DaemonContext should call > > ‘os.initgroups’ > > > > for the target uid and gid? > > Yes, I think this would do it, and I think it would be an > enhancement to make this optional/configurable, e.g. via a new, > optional parameter enforce_gid_set=True or > preserve_user_groups=False. This request – to set supplementary groups per the target UID's membership in groups – has been requested upstream. The “forwarded” URL above discusses it, and a proposed implementation is described in https://lists.alioth.debian.org/pipermail/python-daemon-devel/2014-December/85.html>. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney signature.asc Description: Digital signature
Bug#773291: Unable to inherit groups from user
also sprach Ben Finney [2014-12-17 02:13 +0100]: > > but even if I do not pass the gid value to DaemonContext, then then > > process is unable to read this file: > > > > -rw-r- 1 root ssl-cert 1704 Dec 16 14:08 > > /etc/ssl/private/ssl-cert-snakeoil.key > > Right, AFAIK a process that began as non-superuser has no way of adding > supplementary groups. So, a process which daemonises itself is no > exception to this. The process starts as root and then passes the target uid/gid to DaemonContext, which drops the root privileges. To me, it seems like it's fully enforcing uid *and* gid, which is probably a desirable feature. But a uid can be a member of multiple groups, and it might also be desirable not to drop those extra groups, as in my case. > Ah, maybe you're thinking the DaemonContext should call > ‘os.initgroups’ > > for the target uid and gid? Yes, I think this would do it, and I think it would be an enhancement to make this optional/configurable, e.g. via a new, optional parameter enforce_gid_set=True or preserve_user_groups=False. Thank you! -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#773291: Unable to inherit groups from user
On 17-Dec-2014, Ben Finney wrote: > Right, AFAIK a process that began as non-superuser has no way of > adding supplementary groups. So, a process which daemonises itself > is no exception to this. > > Do you know of a Posix feature that you expect a non-superuser > process to use when daemonising, in order to gain groups it did not > have before daemonising? Ah, maybe you're thinking the DaemonContext should call ‘os.initgroups’ for the target uid and gid? -- \ “The only tyrant I accept in this world is the still voice | `\ within.” —Mohandas K. Gandhi | _o__) | Ben Finney signature.asc Description: Digital signature
Bug#773291: Unable to inherit groups from user
control: tags -1 + moreinfo thanks On 16-Dec-2014, martin f krafft wrote: > It seems impossible to daemonise a programme with python-daemon > without overwriting additional groups defined for the user that > should run the daemon. Evidently this isn't necessary for daemonising; I think “impossible to daemonise” is a mischaracterisation of this behaviour. The process daemonises just fine, it can only do what the OS allows it to do. > but even if I do not pass the gid value to DaemonContext, then then > process is unable to read this file: > > -rw-r- 1 root ssl-cert 1704 Dec 16 14:08 > /etc/ssl/private/ssl-cert-snakeoil.key Right, AFAIK a process that began as non-superuser has no way of adding supplementary groups. So, a process which daemonises itself is no exception to this. Do you know of a Posix feature that you expect a non-superuser process to use when daemonising, in order to gain groups it did not have before daemonising? -- \ “During the Middle Ages, probably one of the biggest mistakes | `\ was not putting on your armor because you were ‘just going down | _o__)to the corner.’” —Jack Handey | Ben Finney signature.asc Description: Digital signature
Bug#773291: Unable to inherit groups from user
Package: python-daemon Version: 1.5.5-1 Severity: normal It seems impossible to daemonise a programme with python-daemon without overwriting additional groups defined for the user that should run the daemon. For instance, I am trying to run bcfg2-server, which does self.context = daemon.DaemonContext(uid=self.setup['daemon_uid'], gid=self.setup['daemon_gid'], …) and the user to use is uid=105(bcfg2) gid=111(bcfg2) groups=111(bcfg2),110(ssl-cert) but even if I do not pass the gid value to DaemonContext, then then process is unable to read this file: -rw-r- 1 root ssl-cert 1704 Dec 16 14:08 /etc/ssl/private/ssl-cert-snakeoil.key -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.17-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
