FS#26640 - [udev] udev, thunar, brasero and group "storage"?
Attached to Project:
Arch Linux
Opened by René Herman (rene) - Wednesday, 26 October 2011, 23:12 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 06 November 2011, 23:16 GMT
Opened by René Herman (rene) - Wednesday, 26 October 2011, 23:12 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 06 November 2011, 23:16 GMT
|
Details
Description:
The upgrade to udev-174 switched optical drives from group "storage" to group "disk". Given that I don't want to give my user access to hard drives as well, I reassign them to group "optical" (of which my user is a member) through a custom udev rule: === /etc/udev/rules.d/81-optical.rules # # udev-174 assigns optical drives to group "disk"; reassign to group "optical" # # Permissions for IDE CD devices SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical" # Permissions for SCSI CD devices SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical" === Upon seeing no device files being owned by group "storage" anymore, I deleted my user from the "storage" group. I'm on an XFCE desktop and have Thunar setup to "Mount removeable drives when hotplugged" but not to "Mount removeable media when inserted". Upon inserting a CD/DVD I do get a desktop-icon, but mounting through the right-click menu at this point fails with "Not Authorized". It used to work fine before udev-174 -- and adding my user BACK to group "storage" fixes the issue (note, both /dev/sr0 and its accompanying /dev/sg1 are in fact owned by groep "optical" after installing that custom rule, and my user is indeed a member of group "optical". nothing in /dev is owned by group "storage"). Thunar isn't the only app affected: Brasero has similar trouble: https://bugs.archlinux.org/task/20035#comment84866 (I only noticed the Thunar trouble after supplying that comment) This probably means this issue belongs with udev? I also don't suppose it's purely upstream? That seemingly hardcoded "storage" group dependency might be an archlinux thing? Or is it just me... Additional info: * package version(s) udev-174-1 thunar-1.2.3-1 thunar-volman-0.6.0-2 brasero-3.2.0-1 Steps to reproduce: Remove your user from the "storage" group and try to mount through the right-clock menu in Thunar or eject through Brasero. |
This task depends upon
Closed by Tom Gundersen (tomegun)
Sunday, 06 November 2011, 23:16 GMT
Reason for closing: Upstream
Additional comments about closing: /dev/srX will be in the optical group again in udev-175. In the meantime, add rule given in last comment if needed.
Sunday, 06 November 2011, 23:16 GMT
Reason for closing: Upstream
Additional comments about closing: /dev/srX will be in the optical group again in udev-175. In the meantime, add rule given in last comment if needed.
I have udisks-1.0.4-1 installed.
===
[Local Users]
#Identity=unix-user: your_username
Identity=unix-group:storage
Action=org.freedesktop.udisks.*
ResultAny=yes
ResultInactive=no
ResultActive=yes
===
This file is installed by thunar:
===
# pkgfile /etc/polkit-1/localauthority/50-local.d/org.freedesktop.udisks.pkla
extra/thunar
===
I just now reinstalled thunar to make sure I never edited it, and yes, it's vanilla Thunar. I'm not sure how this stuff is supposed to work but this feels a bit peculiar?
(Yes, I do start my session through ck-launch-session. As advised at https://wiki.archlinux.org/index.php/SLiM#PolicyKit, in /etc/slim.conf I have
login_cmd exec ck-launch-session /bin/bash -login ~/.xinitrc %session
combined with an otherwise plain archlinux ~rene/.xinitrc that [starts dbus-launch from /etc/X11/xinit/xinitrc.d/30-dbus and] execs xfce4-session.)
If this means it's a Thunar issue, is it possible to change that in the topic and transfer this report to Thunar? The Thunar arch wiki page does mention adding the user to the storage group in the context of automounting but at least I find it rather counter-intuitive that I still need to do so after having no device files belong to that group anymore...
I guess the correct question might be "why did the udev-174 upgrade stop handling group 'storage'?". It seems that at least Thunar by default needs the group (if only due to it wanting users to be part of it; it supposedly wants this due to the fact that it USED to be necesary for them to be part of this group back when it was also the way to provide them access to the devices themselves).
optical drives (at least non-ide drives, which are the only ones as of linux 3.1) should be in the optical group by default, and not in disks/storage. It is true that some things (usb sticks) that used to be in storage are now in disks, but cdroms should not be one of them.
If everything works the way it should when your user is in the storage group, even if the device is in the optical group, then this is not a udev problem. You are still free to be in the storage group even with udev-174, it just does not assign any devices to that group.
It sounds a bit odd for brasero/thunar to check for this group in their PK rules. Maybe looking for "optical" would make more sense, or just rely on the local user getting access through CK?
None. I used to have no custom rules at all, but after the upgrade to udev-174 my SATA DVD-RW drive (/dev/sr0) was now owned by root.disk.
Given that user "rene" wasn't a member of group "disk", this resulted in an inability for "rene" to burn CD/DVDs and upon investigating I encountered more people with the same problem, for example at:
https://bbs.archlinux.org/viewtopic.php?id=129044
(I took my custom udev rule from comment #3 there). If you are saying that my DVD drive SHOULD have been root.optical without any custom rule installed, then I guess that's the part of the problem that's directly related to udev: it is not. Not for me, not for at least a few others -- and I was up to now assuming that it was for no one.
Yes, the "storage" group thing is relatively decoupled. After installing the custom rule, and without my user a member of group "storage", both Thunar and Brasero can do SOME things with my DVD drive again. For example, Thunar can eject an automounted CD/DVD (but can not manually mount it) and Brasero can burn a CD/DVD (but cannot eject it at the end automatically, nor through its menu).
The Brasero bit is perhaps best to forget, since Thunar may be interfering there, so let's just say that without my user a member of group "storage", Thunar cannot mount. In so far that this is a problem (I find it to be unexpected, opague behaviour, without any device node owned by group "storage") it seems to foremost be a Thunar problem, not so much udev. In mere practical terms, adding the user back to group "storage" solves/hides the issue...
However, it does seem to show that group "storage" is being assumed by programs, Thunar at least, on the system and this beckons the question of why the upgrade to udev-174 stopped assignment of my drive to the storage group (independent of whether or not it should have been to "optical" instead of to "disk"). The upgrade commented that it did such but did not explain why. If a "storage" group dependency such as the Thunar one is not simply to be considered a Thunar bug, I believe that this may be an argument as to whether/why udev should restore the former behaviour of assigning these drives to group "storage", at least until all such dependencies have been flushed from the rest of the system?
Note, may. I'm the type of "old time user" who lost track at the udev/consolekit/policykit/dbus stage. I have little oversight how everything is INTENDED to work.
As in, back when the actual device nodes where owned by group "storage", I found it to be perfectly sensible that I needed to add my user to that group in order to give Thunar/Brasero access to it, but after udev-174 I find it to be fairly nonsensible that I now need to add my user to TWO groups; one the group that owns the device node, and two group "storage". Moreover, while having to do that indeed feels more like a Thunar problem than a udev one, I'm still wondering why udev changed it in the first place and if it should not perhaps be restored until oddities such as the Thunar one are purged from the system.
One is: cdrom is in the disk group rather than the optical group. What we need here is the output of "udevadm info -a -n /dev/sr0" (or whatever your cdrom node is).
The other is: Thunar can not mount cdrom. I'm not sure exactly what is going on here, but the policykit file (which is added by Arch, and not upstream) seems wrong. CK should give you permission to deal with the cdrom, but the above bug probably has to be solved first.
However, as to opening a separate report for the Thunar problem/oddity, that does sort of require me knowing what the nature of said problem is.
Before this thread happened, I wasn't even aware that the drive being assigned to "disk" rather than "optical" wasn't intentional, and had as mentioned already "fixed" that part locally through a custom udev rule. It's the Thunar/Brasero trouble that is in fact central to this report and I am trying to ascertain the reason why that problem surfaced in the first place. That is, like was asked a few times now, why udev changed the assignment to group "storage".
Only after an arch linux udev person says "we did that because <foo> and yes, we're certainly going to keep it that way" am I able to report to the Thunar maintainers what the nature of THEIR problem is (or if they even have a problem). That is, if that Thunar PK rule needs to just dissappear, be changed, be replaced by something else, be ...
Looks like I got the wrong end of the stick with regards to group membership of /dev/sr0 (a good example why these things should be maintained upstream ;-) ).
I haven't been able to verify this with upstream yet, but I think the intention is that /dev/srX is in "disk" and the corresponding /dev/sgY is in "optical".
Could you paste the output of "ls -lah /dev", and of "lsmod" with old and new udev, without any custom rules installed?
Attached are "ls -lah /dev" on 3.1.0 with udev-173-3 and again with udev-174-1, and after cutting out the date column, here's the difference. /dev/sr0 moved from group "optical" to group "disk". Not sure why it's not in "storage" instead with 173-3 in this listing (no custom rules installed).
EDIT: Attached the .diff as well in stead of pasting it in due to the variable-width font here. Very unhelpful.
Just before posting I see I forgot to get the lsmod results. Will get and add them to the next comment.
Just to clarify one last thing: am I right in thinking that if you are _not_ in the "storage" group, thunar fails with both udev versions, and if you _are_ in the "storage" group it succeeds with both versions?
Limiting to Brasero since it's behaves most transparently:
Without my user a member of group "disk", and with or without the Thunar pollkit file (see #3) in place and with or without my user a member of group "storage", Brasero in this situation bombs out. No burning, no blanking, no ejecting.
If your above mentioned expectation that /dev/sr0 should indeed be in group "disk" is correct, it would seem that at least Brasero will just not work unless users add themselves to the "disk" group (not a good idea), reassign /dev/sr0 to group "storage" (didn't arch used to do that for them?) or reassign /dev/sr0 to, for example, group "optical" but still make sure they are also a member of "storage" to also have ejecting (and Thunar) work.
Yech. Things used to work relatively transparently through the storage group. Again, why did that stop?
If I'm not in group "storage" with udev-173, it's a mixed bag. It has /dev/sr0 in "optical" and I am also a member of group "optical" and can therefore do SOME things. Thunar for example can eject (but not manually mount), and Brasero can burn (but not eject).
If I'm not in group "storage" with udev-174, and not in "disk", I basically cannot do anything.
If I'm not in group "storage" with udev-174, but am in "disk" or have reassigned /dev/sr0 to some other group that I am a member of (ie, "optical") we're back at the 173 behavior.
Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0 (although, as this report started, I find having to also be in group "storage" if that is not in fact that latter group unexpected, opaque behavior).
Another point: mounting, ejecting, etc. should when everything is fixed work even if your user is not in any groups at all (ConsoleKit should give the correct permissions). That said, I'd still like to sort the group ownership out.
"Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0"
I should clearly say
"Everything works on both versions with my user in group "storage" AND in the group that owns /dev/sr0 AND in the group that owns the accompanying /dev/sgN".
So lovely...
https://bugs.archlinux.org/task/20035#comment84866
brw-rw---- 1 root disk 11, 0 2. Nov 23:12 /dev/sr0
I don't use any display manager. I start my Awesome and Xfce desktop with exec ck-launch-session foo.
root:disk permission seems to be a bug in udev to me. The same happens with LTS kernel and udev-compat.
Which it doesn't do currently. Also, the current upgrade to xfce4-session 4.8.2-2 just now stopped my ability to reboot my computer from within XFCE since now group "power" ALSO doesn't make any difference anymore: it deleted the other .pkla files in my /etc. Which is, I'm sure, a good thing. It's just that nothing works anymore, but hey, I shouldn't be using slim. It's broken. Now, when I just now tried to quickly replace it by lxdm, that didn't work either since lxdm doesn't listen to a "nullok" setting in its PAM file; but I'm sure that's a good thing as well. I mean, no one should be using null passwords, right? Installing GDM drags in basically all of GNOME which seems to basically be the answer on current Linux systems. Install GNOME and conform or be damned.
Sorry, as indicated, replacing slim with something else to test will have to wait a bit again. I now have to reboot to Windows XP again to get some actual work done involving 3D apps that lock up intel-dri on Linux. Wonder if Ctrl-Alt-Del works.
But I still love thinking of myself as someone who thinks Linux is actually useful and not just one gigantic waste of my time. I'm l33t like that.
What we should aim for is that everything (poweroff/mounting of drives/...) should work even if you are not the member of any group. If it does not, something is wrong. As I said, the best would be to compare with GDM first to figure out where to start.
However, it is also the case that /dev/srX should be in 'optical' after all. This will be fixed in udev-175. If you want to fix it before that I suggest adding a rule file '51-tmp-optical-fix.rules' to /etc/udev/rules.d/ containing the line
SUBSYSTEM=="block", KERNEL=="sr[0-9]*". GROUP="optical"
Remember to remove it when the next udev version is out though.
As to you thunar/brasero problems, they should be sorted out by making sure consolekit is assigning ACL's properly. I will close this bug as 'upstream' (referring to the udev permissions).