PEP 3143: Standard daemon process library

[Ben Finney]

Jean-Paul Calderone <exarkun at divmod.com> writes:

> On Tue, 24 Mar 2009 15:42:46 +1100, Ben Finney <bignose+hates-spam at benfinney.id.au> wrote:
> >That sounds rather more specific than is needed for the generic
> >library being proposed here. I'm wary of adding features to an API
> >that is already quite complex.
> >
> >Isn't setting the EUID and EGID something that is just as easily
> >done *after* the program achieves a daemon process?
> 
> That depends.
> 
> If you mean that one can ignore the uid and gid setting features of the
> proposed library so that they are not changed during daemonization and
> then make the appropriate calls from the application afterwards, then
> yes.

Yes, that's what I meant.

> Otherwise, no. Since this means all of your daemon startup code is
> forced to run as a privileged process when it might otherwise have
> run without those privileges

Er? You can still set the real UID and GID via the DaemonContext API,
and then also set the EUID and EGID.

> I think it's worth the tiny additional complexity it will bring to
> the API (and it really is pretty tiny, something on the order of a
> new `set_effective=True´ flag).

It leads immediately to the request to set *both* real UID/GID *and*
effective UID/GID to separate values.

Can you describe the use case more, so I can understand better how
common it might be? In what circumstances must one not change the real
UID/GID but instead change the effective UID/GID, *and* must change
them during daemonisation?

-- 
 \          “One thing vampire children have to be taught early on is, |
  `\                      don't run with a wooden stake.” —Jack Handey |
_o__)                                                                  |
Ben Finney