[PATCH] Udev integration: udev rules 1/3

[PATCH] Udev integration: udev rules 1/3

[Peter Rajnoha]

This is the basic udev rule for DM. It creates nodes in /dev/mapper directory.
The permission for devices are defined here. This one is parsed as the first
one. If we detect LVM-* prefix in DM UUID, we skip the cookie notification,
because this is handled in another rule (similarly, we do this for other
subsystems, if we need to do more actions -- create more symlinks etc.)

(this rule should have the highest priority of all LVM/DM udev rules)

Peter


# udev rules for DM devices
# This will create nodes in /dev/mapper directory.

KERNEL=="device-mapper", NAME=="mapper/control"

SUBSYSTEM!="block", GOTO="dm_end"
KERNEL!="dm-[0-9]*", GOTO="dm_end"
ACTION!="change|remove", GOTO="dm_end"

# "dm" sysfs subdirectory is available in newer DM versions only.
# We have to check for its existence and use dmsetup tool instead
# to get the DM name and UUID if this subdirectory is not present.
ACTION=="change", TEST=="dm", ENV{DM_NAME}="$attr{dm/name}", ENV{DM_UUID}="$attr{dm/uuid}"
ACTION=="change", TEST!="dm", IMPORT{PROGRAM}="/sbin/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o name"

# Default permissions for DM devices.
KERNEL=="dm-[0-9]*", OWNER="root", GROUP="root", MODE="0600"

# You can define your own permissions for DM devices here.
# ENV{DM_NAME}=="my_device", OWNER="peter", GROUP="peter", MODE="0644"


ACTION=="change", NAME="mapper/$env{DM_NAME}"

# We won't send notifications for known subsystems since
# these have their own dedicated rules and the notification
# will be done after they finish their own actions.
ENV{DM_UUID}=="LVM-?*", GOTO="dm_end"

ENV{COOKIE}=="[0-9]*", RUN+="/sbin/dmsetup notify $env{COOKIE}", OPTIONS+="last_rule"

LABEL="dm_end"

[PATCH] Udev integration: udev rules 1/3

[Peter Rajnoha]

On 04/08/2009 02:34 PM, Peter Rajnoha wrote:
> ACTION=="change", TEST!="dm", IMPORT{PROGRAM}="/sbin/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o name"

...ehm, sorry, this should be:

ACTION=="change", TEST!="dm", IMPORT{PROGRAM}="/sbin/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o name,uuid"

Missed the "uuid" field at the end -- otherwise the notification would
come prematurely in DM udev rule and not in LVM. We have to check this
uuid for prefix, and when there's an "LVM-" prefix, the notification
is done by the other rule -- the LVM one. This way it's correct.

Peter

[PATCH] Udev integration: udev rules 1/3

[Alasdair G Kergon]

On Wed, Apr 08, 2009 at 02:34:02PM +0200, Peter Rajnoha wrote:
> # udev rules for DM devices
> # This will create nodes in /dev/mapper directory.
 
/dev and mapper are (separately) configurable, so this script should perhaps
be generated from a template for consistency.
(DM_DIR is fixed at compile time and must match the kernel - set in dm-ioctl.h)
(/dev gets interesting if people invoked lvm with a private lvm.conf with a
private devices/dir - as a minimum assumptions made by the script should be
noted in comments.)

> # "dm" sysfs subdirectory is available in newer DM versions only.

"newer" ?  Be precise - give the version.

> # You can define your own permissions for DM devices here.
> # ENV{DM_NAME}=="my_device", OWNER="peter", GROUP="peter", MODE="0644"
 
Can that be read from a separate file to avoid the need for manual editing
when updating?  (Otherwise add markers so that a postinstall script
can automatically update the file.)

> # We won't send notifications for known subsystems since
> # these have their own dedicated rules and the notification
> # will be done after they finish their own actions.
> ENV{DM_UUID}=="LVM-?*", GOTO="dm_end"
 
Again, how are these prefixes defined?
- Each package will want to install it's own prefix handler.
  Can that be done without having to edit files?

> ENV{COOKIE}=="[0-9]*", RUN+="/sbin/dmsetup notify $env{COOKIE}", OPTIONS+="last_rule"
 
Since this is external input being passed to a trusted program, what is validating it?
- Does that regex have implicit ^ and $ anchors around it?  (If not, add them.)
- What if the variable is defined but empty?  (Change * to +) ?

Alasdair
-- 
agk at redhat.com

[PATCH] Udev integration: udev rules 1/3

[Peter Rajnoha]

On 04/15/2009 08:07 PM, Alasdair G Kergon wrote:
> On Wed, Apr 08, 2009 at 02:34:02PM +0200, Peter Rajnoha wrote:
>> # You can define your own permissions for DM devices here.
>> # ENV{DM_NAME}=="my_device", OWNER="peter", GROUP="peter", MODE="0644"
>  
> Can that be read from a separate file to avoid the need for manual editing
> when updating?  (Otherwise add markers so that a postinstall script
> can automatically update the file.)

Well, once there was this option "udev_permissions" (in /etc/udev/udev.conf)
which specified the directory in which the rules with permissions were
defined only. But it seems this was in past versions of udev and it's not
used anymore (it's not event documented now), so everybody defines the
permissions 'in situ'.

However, we can separate these permissions into a separate file -- it
should not matter if the permission is defined after or before the node
is created (the last permission defined is the one that matters). So we
can probably add a new file with permissions only, *but* then we have to
disable the "OPTIONS+="last_rule", which means that we have less control
over the rules because some other rule can add its own things to our
devices -- I tried this and I defined my permissions and some other
(external) rule changed the GROUP permission to "disk" (I did not
look for the rule which caused this exactly, but it happens...).
So it's safer this way. We have more control.

I've also considered the "IMPORT{FILE}" rule, which can import the contents
of the file, but this is bound to simple "KEY=VALUE" items. It seems we can't
use comparisons here (just like ENV{DM_NAME}=="my_device"). So this is not
the way we want either.

I would probably leave the OPTIONS+="last_rule" in our rules and define
permisssions here. Maybe add some marks, so it can be parsed and filled
in by scripts (as you have suggested) to add new permissions/subsystems.

>> # We won't send notifications for known subsystems since
>> # these have their own dedicated rules and the notification
>> # will be done after they finish their own actions.
>> ENV{DM_UUID}=="LVM-?*", GOTO="dm_end"
>  
> Again, how are these prefixes defined?
> - Each package will want to install it's own prefix handler.
>   Can that be done without having to edit files?

...the same here.

>> ENV{COOKIE}=="[0-9]*", RUN+="/sbin/dmsetup notify $env{COOKIE}", OPTIONS+="last_rule"
>  
> Since this is external input being passed to a trusted program, what is validating it?
> - Does that regex have implicit ^ and $ anchors around it?  (If not, add them.)
> - What if the variable is defined but empty?  (Change * to +) ?

Oh. Thanks, sure, we should not call notify when it's empty (it's not a big
problem, dmsetup will just properly fail when the input is not given). The thing
with these regexes is that they are not full regexes -- just "*", "?", "[ ]", "-" (range)
and "!" (not) (I haven't seen any other to be used in udev rules, also these ones are
documented only). So what can we do... hmm, maybe:

ENV{COOKIE}=="?*"
(we won't check if it's proper numeric value, dmsetup does that, so we can rely on it)

or

ENV{COOKIE}=="[0-9][0-9]*"
(well, I don't know... a little bit clumsy)

Anyway, if the input for dmsetup is wrong, dmsetup will just fail properly, so this is
not a big deal. The cookie value from kernel should be right.

(these are just my findings, so if I'm wrong with something, correct me, please)

Peter

[PATCH] Udev integration: udev rules 1/3

[Dave Wysochanski]

Which version of udev do you require for these patches?

I am using RHEL5.3 version (udev-095-14.19.el5) - is this enough or do I
need upstream version?

[PATCH] Udev integration: udev rules 1/3

[Peter Rajnoha]

On 04/21/2009 09:52 PM, Dave Wysochanski wrote:
> Which version of udev do you require for these patches?
> 
> I am using RHEL5.3 version (udev-095-14.19.el5) - is this enough or do I
> need upstream version?

I use F10's udev (udev-127-3.fc10.i386). Hmm, udev-095 is quite old,
almost 3 years. I'd need to check changelogs what has changed in udev
since then. Do you have any problems running it?

Peter