start misbehaving deamons as another user than root

[Scott James Remnant]

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
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20070715/a0318626/attachment.pgp