Jean-Paul Calderone <exar...@divmod.com> writes: > On Tue, 24 Mar 2009 15:42:46 +1100, Ben Finney > <bignose+hates-s...@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 -- http://mail.python.org/mailman/listinfo/python-list
