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

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, 2005-03-30 at 18:08 +0400, Roman Kagan wrote:
> 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... :)

Well, sorry if it did sound so. The point is that I don't see any
problem here. We apply all later rules, that don't have a NAME key. That
sounds reasonable to me and is nearly full backwards compatible, which
was the reason to do it that way.

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

Then this soul instructed udev to ignore the device, exactly the same as
that rule will do it today, and that is expected behavior.

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

From the first days on, we can set NAME="" to skip any later rule and
ignor the device. Recently "ignore_device" was added for that, which
does the same.
 
> > > 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"

Oh well, this syntax will not happen with our current udev. If this will
ever be a requirement, we should include a shell instead of our
home-grown parser. :)

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

The creation of the default kernel name is expected behavior. The
problem this patch addresses is the dev.d/ brute-force logic which is a
completely different problem, right?

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

We use SUBSYSTEM-only rules to set permissions. I've also seen some
scripts to return group assignments.
I really don't like the idea, nor see any good reason to support
multiple device nodes with the same numbers.

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

Why? The first rule gets applied. The second is ignored, cause NAME is
included. It's that easy, isn't it?

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

No, it's the same from the beginning on. You get an error in the kernel
log for disk sde, but that disk may be named to "something" by udev and
userspace uses "something" and has no idea what disk it gets the error
for, before it asks the udev-database for the relation. That's not
really nice, if you have hundreds of disks.

Kay



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