Re: [PATCH] udev: add rule based program execution

[Roman Kagan <rkagan@mail.ru>]

On Wed, Mar 30, 2005 at 02:05:09PM +0200, Kay Sievers wrote:
> On Wed, 2005-03-30 at 11:39 +0400, Roman Kagan wrote:
> > On Tue, Mar 29, 2005 at 04:54:03PM +0200, Kay Sievers wrote:
> > > If a rule should be the last one to be applied
> > > to a device it must use OPTION="last_rule".
> > 
> > IMHO this is going to increase admin's chances to shoot himself in the
> > foot.
> 
> Thats one of thousand ways to shoot yourself. I don't see any problem
> getting bigger here.

Umm, that's not exactly the kind of attitude I'd expect from a developer
of the core subsystem... :)

> >  Imagine someone having installed a rules file causing the
> > processing of a particular type to stop early, and then someone (else)
> > trying to figure out what's wrong with another rules file matching the
> > same devices but happening to go later in the list.
> 
> The only thing that can happen is that you get more symlinks or the
> systems standard permissions gets applied. And that's not bad, I think.

How so?  What if you had a rule to do something to a particular device
type, and then some kind soul included in his package a rules file
telling udev to ignore your devices?

I believe that a rule should be local: the rule writer shold not depend
on other rules to _not_ match the same device.  This appears to be the
only way acceptable to distro maintainers, who would want to add or
remove rules by small independent pieces (files under /etc/udev/rules.d)

> > As to the notorious "too many tty devices" problem, I guess it can be
> > worked around with something like
> > 
> > SUBSYSTEM="tty", NAME=""
> 
> I thought you were arguing for "independent" rules? This makes the
> heaviest dependency on the order of the rules, I can think of. :)

Sorry, this one is busted.  However not in the way you say: rather, it
has no effect at all (as long as the rules are independent).

> > SUBSYSTEM!="tty", HOTPLUG="/some/slow/hotplug/script"
> 
> And if the hotplug-script should be excluded from two subsystems?

Then they all would be listed in the condition clause, e.g.
SUBSYSTEM!="tty"&&SUBSYSTEM!="sound" HOTPLUG="/some/slow/hotplug/script"

Note that it is the creator of the /some/slow/hotplug/script who knows
which devices his rule should, and which houldn't apply to.

BTW isn't the whole "too many tty devices" problem due to the implicitly
appended NAME="%k" catch-all rule?  Maybe it should just be removed, and
instead every device node wanted under /dev be explicitly matched
against a rule in udev config?

> > > After the first rule that
> > > assigns a NAME to a device, all later rules with a NAME key will be
> > > ignored, so it should not change the current behavior too much.
> > 
> > Same problem here: changing the order of the (seemingly independent!)
> > rules may cause unexpected change of which rule applies.  What's wrong
> > with executing all NAME actions?  At worst it'll create multiple device
> > nodes for the same device - big deal...
> 
> No, I don't see any reason to support more than one device node while we
> can do an unlimited number of symlinks.

Again for the locality of the rule definition.

> It's a security nightmare, to
> check the permissions of possibly multiple nodes with the same
> major/minor.

You don't need to.  Each rule's writer is supposed to understand what
he's doing, so you only need to check the permissions of a device node
against the OWNER, GROUP, MODE fields in the NAME action which was
created the node.

In particular, if you happen to have two rules like

KERNEL="kmem", NAME="%k", MODE="0640"

and

KERNEL="kmem", NAME="mykmem", MODE="0666"

your system's security should always be compromised, regardless of the
order in which these rules happen to be evaluated.

> And today we have the inconvenience that the kernel logs errors for
> devices that don't have the same name as the user visible device node.

This must be a recent addition...  My 2.6.11 doesn't care what filenames I
choose for device nodes, nor how many nodes I create for a given device.

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel