[systemd-bugs] [Bug 66861] Permission denied for regular user not in group "audio" to access /dev/snd/seq

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66861

--- Comment #13 from Alain Kalker <a.c.kalker at gmail.com> ---
(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 :-)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20130717/77326310/attachment.html>