set user id for service ?
david at fubar.dk
Tue Sep 19 12:33:42 PDT 2006
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
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
More information about the dbus