set user id for service ?

[David Zeuthen]

Hi,

Sorry for the lag,

On Sat, 2006-09-16 at 16:01 +0100, Scott James Remnant wrote:
> On Sat, 2006-09-16 at 10:49 -0400, Havoc Pennington wrote:
> 
> > What this also means is that the code for the "session programs" and the 
> > code for the systemwide / nobody-logged-in daemon *should* be 99% the same.
> > 
> > Right now we have some historical daemons that are systemwide only and 
> > some historical daemons that are session only, and we need to evolve 
> > them toward the above goal instead.
> > 
> The only piece I don't understand is why to have two separate daemons at
> all.  Why not just have a general "manager daemon" that sits outside the
> user's session, which receives notification that users have logged in or
> out, and turns on/off checking #2?

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.

Cheers,
David