Fedora power management

[David Zeuthen]

On Mon, 2004-11-15 at 21:16 +0100, Sjoerd Simons wrote:
> This takes hal away again from just being a hardware monitor. 

Simply not true; hal just provides yet another service to help
distributors of hal configure hardware and the surrounding system. Just
like callouts.

> Currently we're
> trying to have hal run with the least amount of priviledges in Debian and
> Ubuntu. With these kind of things, that would be very difficult.
>

hald already touches a lot of hardware and that trend will continue when
we get to monitor more stuff like battery status.

I kind of think saying "no callouts" and "run unprivileged" is just not
the right solution - it sounds to me like a copout. Distributors
deploying hal do need callouts and will need the methods.d stuff to
(auto)-configure the hardware. That's my experience from putting hal
into Fedora anyway (we also have callouts to configure printers).

The alternative is having setuid root binaries (e.g. like pmount) for
everything to enforce policy; I'm not sure that is a good idea, compared
to D-BUS methods, for, well, a multitude of reasons. (I do think,
however, that pmount got some advantages over fstab-sync insofar that
you can query settings from e.g. gconf whether the volume should be
mounted async; or to tweak the UID to mount with; you can open a dialog
to interact with the user etc. etc.)

I do agree, however, that too much code runs as root today (see below).

(and anyway, with SELinux, the concept of root is sort of going away -
the hald process just need to be allowed to do certain things).

> Ofcourse i shouldn't just complain, but also give some alternatives in this
> case :)
> 
> Instead of trying to do everything inside hal, one could image a seperate
> deamon for various things (like for example network manager currently is).. For
> my powerbook i've been thinking to write a little program which manages
> /dev/pmu by exposing a nice dbus interface to it and putting some information
> in hal through dbus.
>
> In my opinion advantages of such small deamons:
>  * they can run least amount of priviledged (in the example, 
>    open /dev/pmu and drop privs) 
>  * Can stay small enough to be flexible and easily auditable.
>  * Their dbus interface can be more extensive than what you would want to
>    do directly in hal. 
> 
> This could be intergrated somewhat with your proposal to add (dbus) interfaces
> in something like a info.interfaces property. Afaik there is no reason why
> these interfaces should be limited to what hal itself has available.

Saying "build yet another daemon" is not always the right solution
either. I think you may under estimate all the life cycle issues you get
from having multiple daemons that depend on each other. You also
increase the complexity of developing and deploying software if you
split it into multiple daemons.

I do think, however, NetworkManager is a good example that justifies a
whole separate daemon since it does a lot of stuff like scanning for
networks and communicating with other D-BUS services (such as
NetworkManagerInfo).

What I don't think, however, is having a separate daemon for proving
essentially 'echo <action> > /sys/power/state' justifies a separate
daemon. That would be plain silly.

(btw, sounds like we're just discussing semantics and system
architecture now; e.g. you appreciate the value of having the methods
invoked through D-BUS with all the value that brings to the table)

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?

Cheers,
David


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