[Gllug] HAL and udev

[Nix]

On Mon, 07 Aug 2006, Mike Brodbelt whispered secretively:
> Nix wrote:
>> On Fri, 04 Aug 2006, Mike Brodbelt yowled:
> 
>> One out-of-date paper. But, hey, as of HAL 0.5.8 it dpeends on a new
>> PolicyKit component which is security-critical, contains numerous severe
>> bugs (like not dropping privileges when it should and ignoring its
>> don't- run-as-root option), is intended for sysadmins to customize, and
>> has absolutely no documentation.
>> 
>> Wonderful, isn't it :(
> 
> Oh dear.

Worse, I sent patches in fixing some of that half a month ago. There has
been no response, and the patches haven't been applied.

Time to send a ping...

(done)

>          There's some slides I found from a recent talk at OLS where
> they're talking about giving it capabilities like FormatDisk().
> Considering what a hairy black box the whole thing is, that's enough to
> give me chills.

Well, formatting a removable disk doesn't strike me as too terribly
horrible. Formatting block devices in group disk, that's bad, but I
doubt that's the intent. (At least I hope not.)

>                 I can see why the architecture might actually be useful,
> but these sorts of things really need far more transparency. It also
> includes my GNOME pet hate - XML configuration files.

This isn't a GNOME thing, it's a freedesktop thing. But yes, XML config
files are vile and I can't see why anyone would ever want to use them.
(gconf is now emitting merged XML files, so if you add a single schema,
your incremental backup has to back up umpty megabytes of unchanged
bloat as well. Filesystem? What is that? Why would we want to store
keyword->value pairs in there?)

> That was most helpful - thanks. Problem turned out to be that some time
> ago I created some custom udev rules, but the udev syntax has since
> changed, and they'd broken, and prevented the distribution installed
> rule that's supposed to forward events to HAL from working.

A good rule whenever upgrading udev and whenever the distro upgrades it
is to run something like

udevtest /class/mem/null

and make sure that works without errors. (Among other things, if it
doesn't, you'll be somewhat dead at next boot.)

-- 
`We're sysadmins. We deal with the inconceivable so often I can clearly 
 see the need to define levels of inconceivability.' --- Rik Steenwinkel
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug