FS#29048 - [consolekit] No setting the right acl for /dev/snd/seq

Attached to Project: Arch Linux
Opened by Jorge Villaseñor (salinasv) - Thursday, 22 March 2012, 06:44 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 04 November 2012, 16:24 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The acl settings for /dev/snd/seq are wrong. Somehow the acl rules in 70-udev-acl.rules are not being applied to snd/seq but they are applied to snd/timer. Both are created in the same line 50-udev-default.rules:43

This make it impossible to use midi controllers if you are not in the audio group (which is prohibited by PulseAudio if you want multiple users logged in http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup)

I have more info in a forum thread: https://bbs.archlinux.org/viewtopic.php?id=137856

Additional info:
* package version(s): udev 181-5

Steps to reproduce:
1) Execute: getfacl /dev/snd/{seq,timer}
2) See the differences between both of them.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Sunday, 04 November 2012, 16:24 GMT
Reason for closing:  Won't fix
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 22 March 2012, 12:52 GMT
The udev-acl is removed from udev in 182. I suggest contacting Michael Biebl <biebl@debian.org>, thats merged udev-acl in Consolekit [#1]

[#1] http://cgit.freedesktop.org/ConsoleKit/commit/?id=d491e4017d3a098b6a2a4fe5a73989c172dfa035
Comment by Dave Reisner (falconindy) - Thursday, 22 March 2012, 13:09 GMT
Nah, not a udev-acl problem. I can reproduce this (and fix it).

$ udevadm info -q all -n /dev/snd/timer
device node not found
$ sudo modprobe snd_timer
$ udevadm info -q all -n /dev/snd/timer
P: /devices/virtual/sound/timer
N: snd/timer
E: DEVNAME=/dev/snd/timer
E: DEVPATH=/devices/virtual/sound/timer
E: MAJOR=116
E: MINOR=33
E: SUBSYSTEM=sound
E: TAGS=:uaccess:
E: UDEV_LOG=3
E: USEC_INITIALIZED=2830870

Add snd_timer to your MODULES if you need this on a regular basis...
Comment by Jorge Villaseñor (salinasv) - Thursday, 22 March 2012, 17:14 GMT
Hi Dave. I think I didn't explained myself.

I do have /dev/snd/timer and it do have the right permissions in snd/timer.

Also I do have /dev/snd/seq but this last one doesn't have the right permissons. I mentioned snd/timer because they both are created in the same udev rule but differ at the moment of applying the acl.

Gerardo: Then I need to wait to udev make a release and it hit arch repo?

I haven't that clear how this udev-ConsoleKit interaction works. Do you think the issue will go away with this migration to ConsoleKit?
Comment by Dave Reisner (falconindy) - Thursday, 22 March 2012, 17:33 GMT
Just because the node exists in /dev does not mean the device is present. You can go and create as many nodes named whatever you want which are all aliases of /dev/null. Unless the module is the loaded, the entry in sysfs will not exist and udev will skip over applying permissions on this node.

My mistake on using /dev/snd/timer as an example above, but its still applicable -- please make sure both modules (snd_seq and snd_timer) are loaded and rerun 'udevadm trigger' as root.

/lib/udev/udev-acl still exists in udev-181. I do not believe 182 will be pushed to the repos without the ACL tool (either reverted in udev or pushed with new consolekit) as it'll break a _lot_ of desktops.
Comment by Jorge Villaseñor (salinasv) - Friday, 23 March 2012, 04:49 GMT
Ok. I have just arrived home and tested it.

I have added snd_seq to MODULES and it did work.

Now I wonder why the module gets loaded automatically when I do am in the audio group? Can we "emulate" this behavior when not in the audio group?
I still feel that having it in the MODULES array is kinda of a hack. Do you think it is there some cleaner way to get it working?
Comment by Dave Reisner (falconindy) - Friday, 23 March 2012, 09:47 GMT
Because you have permission to read the device node, devtmpfs is able to trigger a load of the module on access. It's a catch 22 with ACLs -- you need the ACL to get permission to use the node, but you need module loaded to get the ACL.

No, adding it to MODULES isn't a hack. That's what the MODULES array is there for.
Comment by Tom Gundersen (tomegun) - Friday, 23 March 2012, 10:05 GMT
Udev applies permissions to nodes before the modules are loaded. Would be cool if acls could be applied to. MODULES array is nevrr the solution :-)

This has to be taken to udev/consolekit/systemd upstream.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 08 June 2012, 00:44 GMT
  • Field changed: Summary ([udev] No setting the right acl for /dev/snd/seq → [consolekit] No setting the right acl for /dev/snd/seq)
  • Field changed: Status (Assigned → Waiting on Response)
status?
Comment by Jorge Villaseñor (salinasv) - Tuesday, 02 October 2012, 22:35 GMT
  • Field changed: Percent Complete (100% → 0%)
It's not fixed. Do ConsoleKit's maintainer can talk with upstream?
Comment by Tom Gundersen (tomegun) - Tuesday, 02 October 2012, 22:36 GMT
ConsoleKit upstream is apparently dead. We could consider discussing this with systemd upstream though. I won't promise anything, so if you want this, might be best to take it upstream yourself.

Loading...