start misbehaving deamons as another user than root

[Philippe De Swert]

Hi all,

On Sun, 2007-07-15 at 13:58 +0100, Scott James Remnant wrote: 
> > 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.

This makes sense as you probably don't want the process that you launch
with a different uid/gid/... to track back to root for file-handles
etc...

> 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.

What would happen in cases where there is no full PAM stuff available?

> 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.

Do we really want users to start/stop jobs? I can't imagine where giving
the user nobody the privileges to start/stop jobs would be a good idea
for example.

Anyway in my use case the user UI should be started by the init system
as there is little interaction from the user possible and there is no
login daemon like kdm, gdm or xdm... And for the obvious security
reasons we don't want the UI and all user apps to be running as root.

Cheers,

Philippe