Fedora power management

[Sjoerd Simons]

On Fri, Nov 19, 2004 at 11:19:53AM -0500, David Zeuthen wrote:
> On Mon, 2004-11-15 at 23:58 +0100, Sjoerd Simons wrote:
> > > What could be far more interesting to discuss is how to decouple this
> > > callout/methods.d stuff from the main hald process in a sensible way so
> > > not all the code run as root. I personally think the right solution here
> > > is to make hald fork() into two processes and make one of them drop
> > > privileges and just listen for hotplug events and monitor stuff (what
> > > hald does today except the callouts, only with dropping privileges). The
> > > other one could do callouts and methods.d stuff. The IPC used could be
> > > really simple or it could be D-BUS in peer to peer mode.
> > > 
> > > How does that sound?
> > 
> > That sounds good. I've been thinking for a long while how to split out the
> > volume_id functionality into a seperate process, because that needs raw read
> > access to the disks.. Which is the most problematic one currently.
> > Unfortunately i don't have the time to work it out somewhat more.
> > 
> > The main point i was trying to make is that's it's sometimes better to make
> > a seperate entity for security and flexibility reasons. Having the
> > posibility to redirect some of the interfaces to something really separate
> > only helps to make that easy, so i guess it's worth some consideration. I
> > think we can all agree that we don't want a kitchen sink included in hal
> > :).. 
> > 
> 
> My plan is to do it the following way
> 
>              +------------------------+
>              |          hald          |
>              +------------------------+
>               |            |         |
>               |            |         |
>         +----------+  +---------+   +-------------+
>         | callouts |  | methods |   |  volume_id  |
>         +----------+  +---------+   +-------------+
> 
> where callouts, methods and volume_id are processed spawned by hald. The
> hald and volume_id processes will run with restricted privileges as the
> haldaemon user except for privileges needed to do the work (e.g. the
> patch Martin sent). All IPC between the processes will be D-BUS in peer-
> to-peer mode.

Sounds nice. The biggest problem i currently have with the way we use hal is
that we need to juggle with the device permissions so hal can at least read the
labels of removable devices. So a separate volume_id will be a very big
improvement.  
  
> The processes callouts and methods will run as root and will, as the
> very first thing they do, read a configuration file that tells what
> executables they are allowed to invoke; under what circumstances they
> should be invoked under and so forth. 
> 
> When service is needed the hald process will invoke a single method,
> e.g. Callout() or Method() with the properties, UDI and possibly method
> name of the device. E.g. even though hald is compromised there is no way
> it can execute arbitrary code. 

Sounds reasonable. In case we don't like this setup, we can still choose to
change the callout deamon to run as non-root and do setuid callouts. But
splitting stuff up is nice and gives us flexibility :)
> 
> The executables that the callouts and methods starts will have to be
> careful themselves about dropping privileges.
> 
> I just need to finish some bugfixes for the 0.4.x branch before I start
> this work.

No problem, i also want/need a very stable hal 0.4.x to ship with the Debian 
Sarge release :)..

  Sjoerd
-- 
Circumstances rule men; men do not rule circumstances.
		-- Herodotus
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal