Fedora power management

[David Zeuthen]

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.

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. 

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.

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal