PEP 3143: Standard daemon process library
Ben Finney
ben+python at benfinney.id.au
Tue Mar 24 17:51:55 EDT 2009
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
More information about the Python-list
mailing list