Re: [Utopia] is gmv only ment for mountable stuff?

[David Zeuthen <david fubar dk>]

Hi,

On Tue, 2004-08-03 at 15:00 -0400, John (J5) Palmieri wrote:
> > But you want all the policy handling to be at the session-level anyway,
> > so the program being activated will run as the user logged in. One
> > benefit of handling policy in the session rather than at the system
> > level is that you have access to the users preferences from gconf.
> 
> Well there are instances where you need policy on both sides of the
> stage.  For instance my printer configuration stuff goes like this:
> 
> User Session            || Root
> ======================= || ====================
> printer plugged in      => callout hal_lpadmin
>                         || autodetect driver
> driver selection dialog <= driver not detected 
> driver selected         => driver configured
> 
> =>, <= - DBus or Hal message
> 
> Right now I patching egg-cups to popup the driver selection dialog and
> adding a patch to cups to listen for the driver selection since those
> are already existing daemons.  However if there were no such daemons to
> tack this code onto I would have to create a new daemon.  As it is I
> don't even like the idea of patching cups as I doubt it would ever get
> upstream.  With a policy daemon this is solved because I would just have
> to add each piece to the appropriate daemon (session and root), even
> implementing the configuration of the driver as a policy callout.
> 

With this scheme, I'm not sure I understand how you would avoid patching
cupsd to listen on the signal from egg-cups?

However, I do agree that it would be nice to avoid running a bunch of
daemons in either the session or at the system-level. I see at least two
possibilities

1. Factor out the callout code from hald and produce a daemon, let's
call it hal-policy-manager, that listens for messages from hald on the
system bus. Specifically, we would have an instance on the system-level

 # hal-policy-manager --callout-dir /etc/hal

and for each session

 $ hal-policy-manager --callout-dir $HOME:.hal/callouts:/etc/hal/session

some minor tweaking would be needed in HAL, but nothing serious (we
would need to emit a signal for devices in the TDL just before callouts
are to be run; only hal-policy-manager on the system-level would catch
this, do the callouts, and then invoke a method on hald to transition
the device from the TDL to the GDL). 

An added benefit would be that we could run hald with a lot less
privileges (hald would still start up as root, but we would drop of lot
of POSIX caps as the very first thing). This is actually enough reason
for me to factor out the callout code :-)

Note that with this setup, we would still be able to change how callouts
work, e.g. use rule files to determine whether to call out something,
rather than running all the files in /etc/hal/{device.d,capability.d,
property.d}


2. Write a generic policy manager engine, like the one you described,
that activates daemons when stuff happens, e.g. when HAL adds a new
storage device. I'm not sure whether this is easy - it seems you would
have to "stop" or at least "cache" traffic such that the daemon you're
booting isn't missing any interesting messages.



However, note that some daemons will have to do some stuff when the
session starts and stops anyway. For example, g-v-m should mount all
volumes when the session starts and unmount them when the session ends
like discussed here (it's not yet implemented though)

 http://mail.gnome.org/archives/utopia-list/2004-May/msg00035.html

and I wouldn't be surprised if most "interesting" policy daemons would
need to do the same?

Oh well, enough rambling from me :-)

Cheers,
David