Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 18:54 -0500, Joe Shaw wrote:
> [ Sorry for the late reply, for some reason this whole thread has
> arrived in my mailbox out-of-order and 24 hours late.  sigh.  -j ]
> 
> On Sun, 2004-12-12 at 23:05 -0500, David Zeuthen wrote:
> > Regarding the stability issues, I've seen usb-storage lock up and put
> > hald in state D (uninterruptible sleep) for good too often; while kernel
> > drivers may improve I think all access to device files (fs detection,
> > polling, printer identification, etc.) should be taken care of by
> > programs exec'ed by hald - we may just ignore them if they time out
> > (e.g. the child enters the state D for good). This will ensure that the
> > hald process never ever locks up (on that account at least).
> 
> This sounds like a good idea to me.  I'm not crazy about working around
> broken drivers -- now that large distros with resources and expertise
> ship HAL the onus should really be to fix the drivers -- I realize that
> it's probably an unfortunate necessity to handle processes in diskwait.

Yeah, well, today hald can basically lock up. With the Linux kernel
being sort of a moving target, I'd rather play on the safe side.

> I presume the interaction between the child programs and the daemon will
> be done via dbus with some access control?
> 

The plan I had in mind was basically that child programs use libhal -
this means that this interface needs to be expanded a bit more. For
example, the poller for optical, floppy and IDE zip drives will need to
add/remove child device objects when media is detected in the drive.
Nothing earth shattering though. 

Access control would then be handled through standard D-BUS interfaces
(e.g. only allow haldaemon/root users to call juicy methods).

> >  2) Some centralized management of whether a caller is allowed to invoke
> >     this or that method so it's easier for vendors to patch hal to work
> >     with their auth system (on Red Hat, I would probably use
> >     pam_console).
> 
> Can you elaborate a little more on what you mean here?
> 

Basically, to determine if the calling process (identified by uid and
pid) invoking a D-BUS method is authorized to do so. 

This is not a so big deal today, but for planned high-level operations
such as Eject() on the org.freedesktop.Hal.Device.Block interface or
Setup() on the org.freedesktop.Hal.Device.Block.Crypto (see my mail on
encrypted storage), I imagine distributions are interested in not
letting every random user invoke these. There are other examples of
methods it makes sense to expose. Ideally, such policy should be
expressed in D-BUS but no-one have did this in a distribution
independent fashion yet [1].

For Fedora, I will probably initially use pam_console to only let
authorized users at the console perform such operations. It would make
sense to have a standard auth system to express e.g. that
only /usr/bin/nautilus invoked by an authorized console user may invoke
method Foo() on interface Bar.

I'm not planning to spend a lot of time on this though; the
implementation for Fedora will just be using pam_console.

Stuff like that, basically.

[1] : There is the at_console policy piece in D-BUS but that is
pam_console/Red Hat specific - not very nice.

> > Things I want to fix, for optimization purposes:
> > 
> >  1) we parse all .fdi files on every new device object. Ideally we
> >     should read all of them on startup and cache the rules in memory.
> 
> We may want to keep a "compiled" on-disk database for this.  Maybe
> sqlite or tdb or even berkeley db.  Otherwise I can see memory usage
> getting a bit high especially after, for example, the enormous FDIs for
> all the cameras libgphoto2 supports and sane's scanners.
> 

Yes. I also want to do some benchmarking of .fdi files, it doesn't look
to bad though - computers are fast nowadays. 

I also though about splitting the parser out so anyone can use it -
ideally .fdi files could be used in other areas; e.g. you could define
your desktop policy around .fdi files (e.g. launch flumotion when a
webcam have been inserted, implement g-v-m functionality, popup
notifications) - just a thought (probably not a good idea, .fdi files
are meant to be declarative)

> >  2) there should be a way to control what to callout instead of invoking
> >     out all the callouts for each and every new device object; ideally
> >     this should be tagged through .fdi files (e.g. info.callouts which
> >     is a list of binaries to invoke?)
> 
> FDI files probably make a lot more sense here now than a
> callout-specific format like we talked about doing a long time ago.
> 

Yes, I think so too. It requires some kind of list datatype to stuff
binaries on to.

> I think ideally you'd want things to be based around the callout,
> though.  Its FDI would define what device capabilities it cares about
> and what device properties to be invoked for.  Unfortunately I'm not
> sure how that kind of setup would be wedged into the device-centric
> model.
> 

Yes, the actual callout would install the .fdi file. Callouts when
property changes are probably not too useful; one would install an addon
that listens using libhal to handle that.

> > My target for finishing this work is around mid-to-late-February, which
> > may be a bit ambitious but I'm planning to work full time on it. I will
> > probably not release 0.5.0 before sometime in January.
> 
> I'd ask that changes be as incremental as possible.  We should strive to
> always keep CVS buildable and functional.  It's in no one's best
> interest to land massive changes weeks apart.
> 

That makes sense. My initial idea was to start a new daemon/ directory
and copy changes over but I'm more and more leaning on just hacking on
the existing bits. Some changes are going to be a bit massive though,
Kay's udevd work really makes things a lot easier to deal with. I'll
keep it buildable though.

Cheers,
David


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