start misbehaving deamons as another user than root

[Jerome Haltom]

So how would you go about implementing this? Probably an external helper
application which would actually do the user changes, right?

You would not want to link to NSS modules from inside pid 1. That would
be Evil Bad.

On Sun, 2007-07-15 at 13:58 +0100, Scott James Remnant wrote:
> On Sat, 2007-07-14 at 15:21 +0200, Michael Biebl wrote:
> 
> > > > > I wondered if there was a way to get upstart to start daemons with another
> > > > > user than root. This because some daemons don't drop there privileges decently
> > > > > (or as in my case I need the init system to start them up, but I need them to
> > > > > be running with user privileges)
> > > > >
> > > > > I tried the following in the upstart scripts:
> > > > >
> > > > > su -l username -c daemon-command
> > > > >
> > > > su -l username -c exec daemon-command
> > >
> > > I tried this, unfortunately upstart complains about an unknown stanza, unless
> > > I put it between *script* and *end script* and then it still fails to work as
> > > it does not spawn the daemon process. (It does not work from the command line
> > > either. I also tried with regular commands like ls and the result is the same.)
> > >
> > > Anybody has any other ideas. Of course I can start patching upstart to use
> > > setuid and setgid an then actually launch the application/daemon. Eventually
> > > support for nice can be added too. Is this a good idea?
> > 
> > I don't think it would be that hard to add this kind of functionality
> > to upstart directly and it seems to me to be the right solution to
> > this problem.
> > 
> > Given that we add a uid/gid stanza to the upstart job file format, the
> > question is, if only the exec command would be started under the given
> > uid/gid or also the pre/post-start/stop and script sections.
> > 
> > Scott, what's your take on this?
> > 
> Some kind of user stanza will likely to be added, and as you say, there
> are implementation issues for it.
> 
> I would expect it to take effect for all processes executed by the job,
> included the pre/post-start/stop scripts.
> 
> I would also expect those to be invoked inside a full PAM session; as
> "su", "cron", "at", etc. do; rather than just invoking setuid().  This
> would ensure per-user limits are obeyed.
> 
> Security implications exist as well; it does not seem unreasonable that
> root may start/stop any user's jobs, and that events emitted by root may
> also do the same.  It therefore follows that a user may only start/stop
> their own jobs, and if a user emits an event, then it only affects their
> own jobs.
> 
> Scott