Fedora power management

[Sjoerd Simons]

On Mon, Nov 15, 2004 at 04:17:50PM -0500, David Zeuthen wrote:
> On Mon, 2004-11-15 at 21:16 +0100, Sjoerd Simons wrote:
> > 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.)

pmount is gonna stay very simple, so no linking of libhal and gconf.. On the
other hand we're working on a hal aware pmount wrapper which runs as the normal
user and queries hal's policy items, gconf could be added to that. Although i
think user specific hal properties are more promising for these kind of things.

Note that I'm not against running callouts or even running them as root to 
start with (see below) 
> 
> 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).

Having a lot of code running as root is indeed the main concern. Your right
that SELinux does away with the concept of root, but with the amount of
hardware hald touches it needs to get a lot of priviledges in one process.. 

Also in debian and ubuntu there is basically no SELinux at this time, so that
doesn't help us :( (hopefully this will change rsn).

> > 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.

Your right ofcourse, but just for the sake of it. In my example hal and the 
pmu manager thing wouldn't be dependant. The manager would just push info to
hal in case it was available. 
  
> 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.

The pmu is a lot more then just a /sys/power/state for an apple. And can do
lots of stuff you probably don't want to have in/via hal itself :)
  
> (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?

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 :).. 

  Sjoerd
-- 
The devil finds work for idle circuits to do.
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal