From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Kagan Date: Wed, 30 Mar 2005 14:08:16 +0000 Subject: Re: [PATCH] udev: add rule based program execution Message-Id: <20050330140815.GD2239@katya> List-Id: References: <20050329145403.GA16544@vrfy.org> In-Reply-To: <20050329145403.GA16544@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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_id396&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