set user id for service ?

[David Zeuthen]

On Wed, 2006-09-20 at 01:47 +0100, Scott James Remnant wrote:
> > Well, because such policy daemons (g-s, g-p-m, g-v-m, nm-applet, etc.)
> > 
> >  - show some UI in form of an icon in the notification area (systray)
> > 
> >  - need to interact with the user (notifications, dialogs) before doing
> >    a specific action
> > 
> >  - use gconf libraries to get the settings for a user
> > 
> >  - call into the mechanism provider (for example HAL) as the user on
> >    whose behalf they are running - this is such that the mechanism can
> >    refuse service to the caller dependent on how security policy is
> >    configured. 
> > 
> >    For example, today this security policy is mostly binary; on Fedora,
> >    if you're at the console we allow you to do anything, if you are not
> >    we refuse anything controversial. On Debian I believed this is
> >    similar, only controlled by group membership (plugdev group).
> >    (PolicyKit is an attempt to address this.)
> > 
> > and retrofitting that into a "manager daemon" sounds pretty impossible
> > at worst and hard at best. You'd end up with a proxy running in each
> > desktop session and the "manager daemon" being something that is reduced
> > to a mere mechanism. And we already have such mechanisms in place
> > already.
> > 
> But doesn't Network Manager work this way already?  You have the manager
> daemon running as root, and the policy daemons running as the users?
> 
> This kind of separation seems to make sense to me.

It does and it doesn't make sense to me. You basically get a split into
two processes. It's a mess. It makes it really difficult because you
need to use IPC to transfer user settings from the session daemon to the
system daemon and so forth. You also have a huge lump of code running as
uid 0 which is not desirable in any way.

FWIW, I even convinced my colleague Dan Williams (NM author and primary
maintainer) that NM is broken in this regard and that we should fix it.
The bits doing the heavy lifting will be implemented as method calls on
HAL device objects. Then all policy etc. can be moved to a simple easy
to understand single-threaded daemon instead of the current mess we have
today with two daemons connected by an IPC pipe. It's just a lot of work
and neither Dan nor I have the time to do this right now as we're busy
with other things.

And, to drift even further off topic, when HAL gets enough smarts about
user sessions terminating / becoming inactive, we can add the pieces to
clean up the effects of a users actions when he logs out / his session
becomes inactive. Things like disconnecting his VPN connection,
unmounting the drives he used etc. etc.. Infrastructure like this is
needed to create a secure system.

    David