Bug 66861

It's covered by:
  SUBSYSTEM=="sound", TAG+="uaccess"

Try to load the kernel module first, only after that udev applies the user's
ACLs.

Thanks for the tip and quick reply!

I don't think that udev picking up the device at module load time is the problem, the device does get set to group "audio" by udev (see a looong way below).
I realize that I may have worded the bug subject wrong: it's possibly not a problem with uaccess but with adding the device to a seat. Sorry for that ;-)

In 71-seat.rules, sound devices are handled specially:
71-seat.rules:10:TAG=="uaccess", SUBSYSTEM!="sound", TAG+="seat"
71-seat.rules:11:SUBSYSTEM=="sound", KERNEL=="card*", TAG+="seat"

i.e. anything that does _not_ have KERNEL=="card*" is filtered out for some reason, and doesn't get the "seat" tag.

The trouble is, /dev/snd/seq is a virtual device (alas, without an entry in /sys/devices/virtual/sound , is this an ALSA bug?), and is handled yet elsewhere in:

50-udev-default.rules:33:SUBSYSTEM=="sound", GROUP="audio", \
50-udev-default.rules:34:  OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

i.e. it most probably doesn't have KERNEL=="card*", so does not get "seat" tag.

How do I get /dev/snd/seq added to a seat, given that it has this strange "static_node=" option?

The more I think of it, probably ALSA bug: /sys/devices/virtual/timer exists, /sys/devices/virtual/seq doesn't...

erhhm that should be /sys/devices/virtual/*sound*/{timer,seq} , duh.

Perhaps this (old) post is relevant, since it mentions /dev/snd/seq specifically: http://lists.freedesktop.org/archives/systemd-devel/2012-December/007750.html

I can't figure out from the context how exactly it is (was) handled there.

Created attachment 82372 [details]
Output of `journalctl -b | grep udev` with /etc/udev/udev.conf containing "udev_log="debug"

Not of much use, I'm afraid. The log entries generated by libudev are scattered over multiple processes, so I filtered it on 'udev'.

I'll try to hack together an ad-hoc `udevadm monitor` service next, to get some more detailed output.

One interesting thing found:

$ getfacl /dev/snd/{seq,timer}
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:miki:rw-
group::rw-
mask::rw-
other::---

Yup, that supports my suspicion: the 'timer' device has an entry in /sys, and so it gets the right ACL set. 'seq' has no entry in /sys, and doesn't get right ACL set. Bummer.

As mentioned, if you do:
  modprobe snd_seq
the seq device should show up in /sys.

$ ls -l /sys/class/sound/{seq,timer}
/sys/class/sound/seq -> ../../devices/virtual/sound/seq
sys/class/sound/timer -> ../../devices/virtual/sound/timer

(In reply to comment #8)
> As mentioned, if you do:
>   modprobe snd_seq
> the seq device should show up in /sys.
But that's hardly a solution?

Ahh!, I was assuming that

$ lsmod | grep seq
snd_seq_device          5180  2 snd_rawmidi,snd_opl3_lib
snd                    58893  8 snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_mpu401_uart,snd_seq_device,snd_cmipci,snd_opl3_lib

and the /dev/snd/seq device node existing was all I needed. Never ever realized that I needed to *manually* modprobe snd_seq for it to actually start working.
The distro I was using before Arch had this setup out-of-the-box.

# modprobe snd_seq
$ getfacl /dev/snd/seq
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:miki:rw-
group::rw-
mask::rw-
other::---

Case closed, I think, and sorry for wasting your time...

To add just one more thing:

I don't know if it is due to the "static_node" stuff or if the kernel really does create /dev/snd/seq even before the snd_seq kernel module is loaded, anyway, it would be nice if the error message that started all this had been something like

"/dev/snd/seq: No such file or directory"

instead of:

"/dev/snd/seq: Permission denied"

The former would have me go looking for missing kernel modules, hardware problems etc. immediately, the latter sent me down this twisting path...

Just my 2 cents.

(In reply to comment #11)
> I don't know if it is due to the "static_node" stuff or if the kernel really
> does create /dev/snd/seq even before the snd_seq kernel module is loaded,

Right, it's udev, not the kernel. And things work as expected. It's just
unfortunate, that it does not work for ordinary users who log in. All other
use cases for on-demand module-loading are covered, needed, and will work
fine.

> instead of:
> 
> "/dev/snd/seq: Permission denied"

Hmm, that's pretty actionable, isn't it?

It tells you that you don't have the permission to open the node. Just
throwing a 'sudo' in front, which gets the permissions, would have made everything work.

Btw, future versions of systemd will also handle logged-in users ACLs:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=6b78df0a6ec75f25705a0f78ef895b95ab75a7ea

Thanks!

(In reply to comment #12)
> (In reply to comment #11)
> > I don't know if it is due to the "static_node" stuff or if the kernel really
> > does create /dev/snd/seq even before the snd_seq kernel module is loaded,
> 
> Right, it's udev, not the kernel. And things work as expected. It's just
> unfortunate, that it does not work for ordinary users who log in. All other
> use cases for on-demand module-loading are covered, needed, and will work
> fine.

No, they do not. At least on Arch Linux, which tries to provide packages as 'vanilla' i.e. unpatched, unmodified as possible, no dynamic module loading happens for /dev/snd/seq .

> > instead of:
> > 
> > "/dev/snd/seq: Permission denied"
> 
> Hmm, that's pretty actionable, isn't it?
> 
> It tells you that you don't have the permission to open the node. Just
> throwing a 'sudo' in front, which gets the permissions, would have made
> everything work.

Please *don't* advise users to try to solve problems whose cause they don't know by simply throwing 'sudo' at them. It sounds like "If you hit it and it doesn't budge, just use a bigger hammer."

In this particular case (/dev/snd/seq file exists, snd_seq kernel module not loaded, what happens is this:

$ sudo aconnect -l
[sudo] password for miki: 
aconnect - ALSA sequencer connection manager
Copyright (C) 1999-2000 Takashi Iwai
Usage:
 * Connection/disconnection between two ports
   aconnect [-options] sender receiver
[snip usage text]

The user's confusion will now be complete, s/he might think that sudo 'ate' the -l option, that aconnect doesn't like being run with root privileges, etc.

Only running aconnect under strace with root privileges reveals a tiny bit of extra information, but you'd need a trained eye to spot it:

$ sudo strace -e trace=file -f aconnect -l
execve("/usr/bin/aconnect", ["aconnect", "-l"], [/* 15 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libasound.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
stat("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=9184, ...}) = 0
open("/usr/share/alsa/alsa.conf", O_RDONLY) = 3
access("/usr/share/alsa/alsa.conf.d/", R_OK) = 0
stat("/usr/share/alsa/alsa.conf.d/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/share/alsa/alsa.conf.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/share/alsa/alsa.conf.d//50-pulseaudio.conf", O_RDONLY) = 3
access("/etc/asound.conf", R_OK)        = 0
stat("/etc/asound.conf", {st_mode=S_IFREG|0644, st_size=260, ...}) = 0
open("/etc/asound.conf", O_RDONLY)      = 3
access("/root/.asoundrc", R_OK)         = -1 ENOENT (No such file or directory)
open("/dev/snd/seq", O_RDWR|O_CLOEXEC)  = 3
------------------------------------------^ (>=0, success!)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/alsa-utils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/alsa-utils.mo", O_RDONLY) = -1 
[snip lots of unimportant output]
+++ exited with 1 +++

If unlucky, at this point someone could now decide to compile alsa-lib/alsa-utils from source with debug symbols and fire up gdb...

Just to try and make a point: the different errors (let's call them ENOENT, EPERM and ENODEV for short) do make a lot of difference in a user's perception of the problem:
- "No such device": The (virtual) device doesn't exist, let's try and fix that.
- "No such file or directory": The (virtual) device may or may not exist, first check for the device some other way (dmesg, journald), then try and fix the device file.
- "Permission denied": whoops, the device does exist, but I'm not allowed to access it.

> 
> Btw, future versions of systemd will also handle logged-in users ACLs:
>  
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=6b78df0a6ec75f25705a0f78ef895b95ab75a7ea
> 
> Thanks!

You're welcome :-)

Please ignore my comment above, I misspelled `aconnect -o`.
The module does autoload when using it with sudo.

I'm looking forward to the next version of systemd with your patch included.

Thanks again.