udev rules and group / permission errors [solved] [outdated]

Moo-Crumpus · 2005-05-01 15:34:47

Latest udev is a miracle to me. It ignores every group ore permission settings. Anyone else having same experiences?

Last edited by Moo-Crumpus (2008-09-29 05:17:40)

Stinky · 2005-05-01 15:47:11

lol. Yes. On my computer it is fine. On my buddie's laptop, it ignores the fact that a user is in the audio group and optical group. Had to go into udev.permissions and change the audio devices section from root:audio to root:users. Same thing with the optical devices section. On his laptop, the user is in both the audio and optical group.

i3839 · 2005-05-01 15:50:30

You're aware that /etc/udev/permissions.d isn't used anymore and that the modes are set in the rules now?

Stinky · 2005-05-01 15:56:16

That's interesting, because it started acting normally when i changed udev.permissions and rebooted. hmmmmm :?

Moo-Crumpus · 2005-05-01 15:58:13

of course i noticed udev united rules and permissions into one set. even the standard udev rules give me errors, video is not working, audio is crud, and so on, not to mention my own rules in 00-pinks.rules. I have to chown and chmod my nvidia devices to have permissions, allthough i am part of video etc...

lanrat · 2005-05-01 19:18:42

...and udevd is working (and devfs is not) ?

polarrr · 2005-05-01 20:51:46

Man, that's borked I had some permission problem when I upgraded udev when the latest one came up on the pacman servers as well. For some reason my own 00. udev rules was ignored and was giving me permission problem on one of the CD-ROMs. It was working before and I hadn't touched 00. since permissions got scrapped. I didn't figure out what changed or what happened, but I just grinded the 00. rules with different combination and got it to work again.

Not that my post was helpful but just wanted to tell you

loserMcloser · 2005-05-03 16:07:01

I had a problem recently with the group setting of some custom rules in 00.* being ignored -- my cdroms were being set to "disk" group despite my custom rule specifying "optical". Turns out the line

SUBSYSTEM="block", GROUP="disk"

in udev.rules was causing the problem, just commented it out. But then I had to go through and add GROUP="disk" to any block devices that really should be in the "disk" group.

Not a very satisfactory fix, and I'm not sure why the above line would supercede settings given in 00.*, but it worked...

Moo-Crumpus · 2005-05-03 16:34:51

I don't know if this SUBSYSTEM flag in udev is a new feature. Never crossed my way before. I will have a look at my laptop at home, that is rarely updated, as my kids are allways wearing it around the garden, to impress the neighbourhood with wireless arch.

After some testing @ home, I can tell you the groups are the issue. I can change mode flags, and they are working well, but if I change a group for a device, it is ignored. Let me add I do my own rules in my ruleset, only, and leave udev common rules unchanged. Meanwhile, I have a bunch of rules giving me 0777 permissions, to give me access, and this is kind of assimilated, isn't it. :x

i3839 · 2005-05-03 16:42:09

Hm, what about using the numerical user/group modes instead?

lanrat · 2005-05-03 19:14:21

There are things that you have to remember when you write udev rules but IMO you can be right this time. I think udev doesn't ignore GROUP settings. It first scans 00 file (and for example symlinks work ok) but then it scans basic ruleset file and changes GROUP. In other words last setting (at least permission settings) wins - and I think that's what is changed (previously first rule from 00 file won).

lanrat · 2005-05-03 19:49:56

Ok. I've found that during version upgrade from 054 to 055 there was a new OPTION value added. It's called "last_rule". So this probably works like I suspected: first it reads GROUP setting from 00 file and then the second GROUP setting from basic file which overwrites (?) the first GROUP setting. I think it also works for other things like SYMLINK. To have your own GROUP permission setting you should now have a complete rule (IMO) in your 00 file and add OPTIONS="last_rule" (or OPTION without "S" - there are differences between changelog and udev manual).

EDIT: udev changelog:
http://www.codemonkey.org.uk/projects/b … /ChangeLog

lanrat · 2005-05-03 19:55:24

And the full explanation I've just found:
http://www.codemonkey.org.uk/projects/b … EASE-NOTES

udev 057
========
All rules are applied now, but only the first matching rule with a NAME-key
will be applied. All later rules with NAME-key are completely ignored. This
way system supplied symlinks or permissions gets applied to user-defined
naming rules.
Note:
Please check your rules setup, if you may need to add OPTIONS="last_rule"
to some rules, to keep the old behavior.

EDIT: It would be good to mention this in the news and/or in the newsletter IMO since it's not very easy to find this information (well, at least for some people :-)) and many people can be surprised with this change in udev.

EDIT2: Added comment to already existing bug report:
http://bugs.archlinux.org/index.php?do=details&id=2691

lanrat · 2005-05-04 10:24:26

I'd like to confirm that adding OPTIONS="last_rule" stops processing next rules for a given device and sets GROUP properly:

ls -l /dev/hdc                       
brw-rw----  1 root users 22, 0 2005-05-04 02:28 /dev/hdc

Moo-Crumpus · 2005-05-04 15:33:42

Do I have to add thius option to every rule I want it to have, or how is it handled? I can't get through it, can you give an example?

Is it handled like

# sony clie
BUS="usb", SYSFS{manufacturer}="Palm, Inc.", KERNEL="ttyUSB[0-9]*", NAME="pilot", GROUP="pilot", MODE="0660", OPTIONS="last_rule"

# kobil
BUS="usb", SYSFS{idProduct}="2012", SYSFS{idVendor}="0d46", SYSFS{manufacturer}="KOBIL", SYSFS{product}="USB Adapter K", KERNEL="ttyUSB[0-9]*", NAME="ttyUSB%n", SYMLINK="ct_kobil", GROUP="cardterminal", MODE="0660", OPTIONS="last_rule"

# reiner_sct
BUS="usb", SYSFS{idProduct}="0100", SYSFS{idVendor}="0c4b", KERNEL="ttyUSB[0-9]*", NAME="ttyUSB%n", SYMLINK="ct_cyberjack", GROUP="cardterminal", MODE="0660", OPTIONS="last_rule"

lanrat · 2005-05-04 22:19:07

Let's assume that you have two files with udev rules. The basic udev.rules and 00.udev.rules (with custom rules).

Udev first reads all rules from 00 file and then rules from the basic file.

This means that if you have a custom rule for a given device you should copy all rules that apply to it from the basic file to the 00 file (not only lines with GROUP). This is because with OPTIONS="last_rule" udev will stop processing rules for this device.

All rules are read and then applied in the order from the top to bottom except SUBSYTEM which is applied as the last rule (kind of held in a buffer). This is the reason why my cd burner /dev/hdc had permissions for disk group and not optical.

This is my 00.udev.rules (it still needs some cosmetic changes but it works and of course I don't have all the devices):

SUBSYSTEM="video4linux", GROUP="users"
SUBSYSTEM="sound", GROUP="users"
SUBSYSTEM="printer", GROUP="users"
SUBSYSTEM="block", GROUP="disk"

BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", SYMLINK="%c{1} %c{2}"
BUS="ide", KERNEL="hdc", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", SYMLINK="nagrywarka dvd cdrw", OPTIONS="last_rule"
BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", OPTIONS="last_rule"
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-floppy.sh %k", RESULT="floppy", NAME{all_partitions}="%k", GROUP="users", OPTIONS="last_rule"

BUS="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="scsi", KERNEL="sr[0-9]*", SYSFS{type}="5", NAME="scd%n", GROUP="users", OPTIONS="last_rule"
BUS="scsi", KERNEL="sg[0-9]*", SYSFS{type}="5", NAME="%k", GROUP="users", OPTIONS="last_rule"

KERNEL="fd[0-9]*", NAME="fd%n", GROUP="users", SYMLINK="floppy/%n fd%nu1440 fd%nu720 fd%nh1200 fd%nu360", OPTIONS="last_rule"

BUS="usb", SYSFS{serial}="CN16J1Q3HWSX", KERNEL="lp[0-9]*", NAME="usb/%k", GROUP="users", SYMLINK="drukarka_hp_845c drukarka", OPTIONS="last_rule"
BUS="usb", KERNEL="sd*", PROGRAM="/etc/udev/usb-storage.sh %k", RESULT="1", NAME="%k", GROUP="users", OPTIONS="last_rule"

KERNEL="rtc", NAME="misc/%k", SYMLINK="%k", GROUP="users", MODE="0664", OPTIONS="last_rule"
KERNEL="agpgart", NAME="misc/%k", SYMLINK="%k" GROUP="users", OPTIONS="last_rule"

KERNEL="nvidia*", GROUP="users", OPTIONS="last_rule"
KERNEL="fb[0-9]*", NAME="fb/%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="card[0-9]*", NAME="dri/%k", GROUP="users", OPTIONS="last_rule"
KERNEL="3dfx*", NAME="%k", GROUP="users", OPTIONS="last_rule"
KERNEL="dvb*", PROGRAM="/etc/udev/dvb.sh %k", NAME="%c", GROUP="users", OPTIONS="last_rule"

KERNEL="video[0-9]*", NAME="v4l/video%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="users", SYMLINK="radio%e", OPTIONS="last_rule"
KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"

KERNEL="controlC[0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="hw[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="pcm[CD0-9cp]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="midi[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="timer", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="seq", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="audio*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="dmmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="admmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="dsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="adsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="midi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="amidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="mixer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="sequencer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"

KERNEL="pktcdvd", NAME="pktcdvd/control", GROUP="users", MODE="0660", OPTIONS="last_rule"
KERNEL="pktcdvd[0-9]*", NAME="pktcdvd/pktcdvd%n", GROUP="users", MODE="0660", OPTIONS="last_rule"

The problem with /dev/hdc was that first udev (version 057) was reading a rule from my 00 file (BUS="ide", KERNEL="hdc"...) with GROUP=users. Then it was reading SUBSYSTEM="block", GROUP="disk" rule from the basic file (but it wasn't executed at that time). And then it was reading BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1"... with GROUP=optical. Then it was executing SUBSYTEM rule (hdc is a block device). That's why only disk group had an access to /dev/hdc (with OPTIONS="last_rule" in the basic file in the GROUP="optical" line it would ignore SUBSYSTEM rule).

There are also other rules that you should add (IMO) to your custom rules if you are changing something. In my case it's for example BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k"... which creates symlinks for cd drives. This rule must be above other rules (the number of the symlinks is now unlimited - previously it was 5 IIRC).

So now the rules are mixed together in the lexical order (except SUBSYTEM rules which are executed at the end) unless OPTIONS="last_rule" is used or second (and other) rule has a NAME filed (only one rule for a given device can have NAME filed. Every other rule for the same device with NAME field is ignored IIRC). It also means you can now split rules for a device into several rules - only one of them can have NAME filed and the last should have OPTIONS="last_rule".

Since in your case you have custom rules only for a well defined usb devices (not /dev/sd*) IMO it should work as you think (only add OPTIONS="last_rule").

I hope it's now perfectly clear 8)

Moo-Crumpus · 2005-05-05 13:38:23

Thank you, it is clear. I find this option will make udev ueber-complicated and confusing. Furthermore, I think it is useless. I can't see the need of such a thing.

BigBadPenguin · 2005-05-13 17:25:00

:shock:
Ooooh... So that's why. Thanks all! 8)

tpowa · 2006-01-22 11:06:33

we use optical for cd/dvd stuff

scarecrow · 2006-01-22 11:40:06

There is "optical" in Arch for ages, and for using some kinky (firewire, cardbus etc) burner devices, you can always create and use a "burning" group, as K3B is advising to do in such cases.

Arch Linux

#1 2005-05-01 15:34:47

udev rules and group / permission errors [solved] [outdated]

#2 2005-05-01 15:47:11

Re: udev rules and group / permission errors [solved] [outdated]

#3 2005-05-01 15:50:30

Re: udev rules and group / permission errors [solved] [outdated]

#4 2005-05-01 15:56:16

Re: udev rules and group / permission errors [solved] [outdated]

#5 2005-05-01 15:58:13

Re: udev rules and group / permission errors [solved] [outdated]

#6 2005-05-01 19:18:42

Re: udev rules and group / permission errors [solved] [outdated]

#7 2005-05-01 20:51:46

Re: udev rules and group / permission errors [solved] [outdated]

#8 2005-05-03 16:07:01

Re: udev rules and group / permission errors [solved] [outdated]

#9 2005-05-03 16:34:51

Re: udev rules and group / permission errors [solved] [outdated]

#10 2005-05-03 16:42:09

Re: udev rules and group / permission errors [solved] [outdated]

#11 2005-05-03 19:14:21

Re: udev rules and group / permission errors [solved] [outdated]

#12 2005-05-03 19:49:56

Re: udev rules and group / permission errors [solved] [outdated]

#13 2005-05-03 19:55:24

Re: udev rules and group / permission errors [solved] [outdated]

#14 2005-05-04 10:24:26

Re: udev rules and group / permission errors [solved] [outdated]

#15 2005-05-04 15:33:42

Re: udev rules and group / permission errors [solved] [outdated]

#16 2005-05-04 22:19:07

Re: udev rules and group / permission errors [solved] [outdated]

#17 2005-05-05 13:38:23

Re: udev rules and group / permission errors [solved] [outdated]

#18 2005-05-13 17:25:00

Re: udev rules and group / permission errors [solved] [outdated]

#19 2006-01-22 11:06:33

Re: udev rules and group / permission errors [solved] [outdated]

#20 2006-01-22 11:40:06

Re: udev rules and group / permission errors [solved] [outdated]

Board footer