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

[David Zeuthen <david fubar dk>]

On Wed, 2004-08-04 at 11:43 -0400, Joe Shaw wrote:
> Hi,
> 
> On Wed, 2004-08-04 at 04:09 +0200, David Zeuthen wrote:
> > 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
> 
> How would the session one be invoked by the correct user, short of
> having a daemon listening for some sort of notification?
> 

I was thinking that the session manager would start it for the user when
he logged in?

> > 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 :-)
> 
> If hald drops its privileges, then lifecycle issues worry me.
> hal-policy-manager would have to be a separate daemon because otherwise
> caps would be inherited and you don't want to limit the callouts.  If it
> crashed, there wouldn't be any way to bring it back without restarting
> hald.  And then you have to write some protocol to communicate between
> the two.  Ugh. :)
> 

Right, I was thinking that hal-policy-manager would be started just
before hald by the init scripts. Regarding hald starting and stopping
(and, uhm, crashing :-), yeah, but hal-policy-manager can easily track
the lifecycle of hald (more correctly, the org.freedesktop.Hal service)
using the D-BUS lifecycle interfaces. But, yeah, it's still code that
needs to be written, debugged and audited.

> And all this is assuming the OS supported capabilities, which I think
> only Linux does.  I suspect a lot of people would prefer to use SELinux
> or whatever the flavor of the month is.
> 

Well, of course, nothing prevents you from running both hald and hal-
device-manager as root. But yeah, I would probably prefer SELinux at
some point too.

> > 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.
> 
> I'm not sure how much you'd really need to invoke daemons as much as
> one-off callouts.  g-v-m for example wouldn't need to be a daemon
> anymore.  It could just check the type of media and execute mount and
> whatever program is to be launched.  Hell, we could replace it with a
> shell script. :)

Haha, tell that to Robert.

> > 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) and I wouldn't be
> > surprised if most "interesting" policy daemons would need to do the
> > same?
> 

Another point is that policy daemons might want to maintain state and
short cuts to functionality; e.g. an icon in the notification area.

> Good point.  The generic policy engine could probably handle this as
> it'd be started as a part of the session.
> 

Right. Well. As I've tried to express this engine is still a bit of a
mystery to me; for starters I think it should do more than just invoke
programs when stuff happens on the wire. Don't know.. Could be
interesting to research this though!

Cheers,
David