FS#22337 - [udev] bad usb key group
Attached to Project:
Arch Linux
Opened by Sébastien Luttringer (seblu) - Thursday, 06 January 2011, 01:31 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 30 August 2011, 23:25 GMT
Opened by Sébastien Luttringer (seblu) - Thursday, 06 January 2011, 01:31 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 30 August 2011, 23:25 GMT
|
Details
If i understand right, every usb key should be right/write
by group storage. cf:
https://wiki.archlinux.org/index.php/Group.
One of my usb key, kingston data have the bad group. $ ll /dev/disk/by-id lrwxrwxrwx 1 root root 9 2011-01-06 01:50 usb-Kingston_DataTraveler_2.0_5B870F0000D4-0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 2011-01-06 01:50 usb-Kingston_DataTraveler_2.0_5B870F0000D4-0:0-part1 -> ../../sdb1 $ ll /dev/sdb* brw-rw---- 1 root disk 8, 16 2011-01-06 01:50 /dev/sdb brw-rw---- 1 root disk 8, 17 2011-01-06 01:50 /dev/sdb1 So, rights is set by udev rule file /lib/udev/rules.d/81-arch.rules which match on scsi_level to select usb key $ grep 'GROUP="storage"' 81-arch.rules KERNEL=="sd*", ATTRS{scsi_level}=="3", ATTRS{type}=="0", GROUP="storage" KERNEL=="sd*", ATTRS{scsi_level}=="5", GROUP="storage" KERNEL=="sd*", ATTRS{scsi_level}=="3", ATTRS{type}=="7", GROUP="storage" KERNEL=="hd*", ENV{ID_TYPE}=="generic", GROUP="storage" but this key seems to have scsi_level =0. has you can see with lssci or via sysfs. $ lsscsi -l 12:0:0:0 [12:0:0:0] disk Kingston DataTraveler 2.0 PMAP /dev/sdb state=running queue_depth=1 scsi_level=0 type=0 device_blocked=0 timeout=30 We need to patch this rule file to better match usb key. My first plan was to add my scsi_level in file but, i look how debian handle do and to be honnest, it's really more sexy. In debian usb key have group floppy. $ grep 'GROUP="floppy"' /lib/udev/rules.d/* 91-permissions.rules:SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy" 91-permissions.rules:SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394|mmc|pcmcia", GROUP="floppy" 91-permissions.rules:KERNEL=="cbm", GROUP="floppy" So, I propose to doing the same matching. |
This task depends upon
I don't know enough to do anything about this atm though, I will try to study it to get a better understanding.
Again, I need to look into the "correct" way to do this.
Maybe you're right about concept of storage group, but we need to keep in mind, some users needs to mount opticale and/or removable devices without be root.
About classification of removable devices i don't understand, kernel export un parameter via sysfs to specify about removability as you can see in rules:
+SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="storage"
I look into debian before sending this patch and they consider storage as floppy.
I agree we need to keep our custom groups or group renaming (which is done in the PKGBUILD file). So we will always rename "tape" to "storage", but I don't think it is correct to add these devices to the storage group.
The "removable" attribute, is not reliable as far as I understand. If it _is_ reliable this should be taken advantage of by udev upstream (there was just a discussion on the udev ml about something related to this, and the conclusion was AFAICT that classifying this is impossible in general).
Any reason that users can not use udisks? If I understand correctly, this is exactly the problem udisks is meant to solve.
PS: in my opinion suse is the distro to look to for how to deal with udev, they have a very KISS approach that i like a lot.
For example, you plug an usb key and you want to partition it. fdisk or gdisk, not udisks.
Another one, i plug and external disk (eSATA) and i directly run virtualbox on it.
I often do this two things.
To resume my current point of view. There is
disk - Which are devices where you should not have write access as user (security reason). This is like given a root access to my system fs.
storage - external plugged storage devices ("power" user and me want to be able to write on usb key / external sata quietly)
optical - external plugged cdrom/dvd/blueray disk (i want to be able to write on my cd quietly)
floppy - external floppy disk (i want to be able to write on my floppy quietly)
I remember that pmount make a difference between "removable" and not removable devices with a poor pattern matching on devices name.
udisks have in its rights database the 2 actions
$ pkaction|grep udisks|grep -- -mount
org.freedesktop.udisks.filesystem-mount
org.freedesktop.udisks.filesystem-mount-system-internal
do udisks make difference between system internal (our disk group) and mount (storage group). I didn't look into the code, but they probably have a way to check this.
about reliability of sysfs "removable", as far i know, it's a hint like many others to know if a devices is removable. But I'm technically very light, saying it.
I will look how suse do. Thanks.
PS
Check out the newest 81-arch.rules from svn, it is now much smaller than before.
i tested with your last version of 81 (http://projects.archlinux.org/svntogit/packages.git/tree/udev/trunk/81-arch.rules) and your new 20 version
usb key are no more in storage group when you set storage with 20. I tried with 80 and it was fine. So 20 is a little too low.
About removable arg, i must need more test with eSATA, i believe it doesn't work.
The main reason is security, by giving group access to devices you would allow remote users accessing local devices, which the local user might not expect. In general, there should never be any reason to put users in groups to access hardware, tools such as policykit, consolekit and udisks should hand out the required permissions when needed.
The original use-case from seblu was to be able to partition and format devices such as usb keys. I just installed gnome-disk-utility to have a look at how this works, and I can confirm that I could both partition and format my SD card, so this should not be a problem.
I'll close as won't fix, and remove all the related rules in the next udev release.
Thanks for taking the time to report anyway, and for helping me figure out what should be done.