From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: The permissions in /dev/snd/* prevent use of alsa sound. New rules and use of udevstart don't fix it, and behaviour is different for x86_64 and i386 systems. Version-Release number of selected component (if applicable): udev-058-1 x86_64 and kernel-2.6.12-1.1447_FC4 x86_64 How reproducible: Always Steps to Reproduce: 1. As ordinary user, dad, run aplay - aplay /usr/share/sounds/warning.wav It fails. 2. As root, do the same. It plays correctly. 3. Expected Results: aplay should work for any user. Additional info: Perhaps this should be filed under 'alsa', but I think not. While trying to get sound working on a new x86_64 system, I discovered that aplay worked for root, but not for me - dad. This was due to the permissions on files in /dev/snd: # ll /dev/snd total 0 crw------- 1 root root 116, 0 Aug 31 10:36 controlC0 crw------- 1 root root 116, 24 Aug 31 10:36 pcmC0D0c crw------- 1 root root 116, 16 Aug 31 10:36 pcmC0D0p crw------- 1 root root 116, 25 Aug 31 10:36 pcmC0D1c crw------- 1 root root 116, 18 Aug 31 10:36 pcmC0D2p crw------- 1 root root 116, 1 Aug 31 10:36 seq crw------- 1 root root 116, 33 Aug 31 10:36 timer When I changed this, eg, chmod 0666 *, aplay as well as xmms worked properly. Clearly, these permissions are wrong, so I looked for a permanent fix, less brute force than installing in /etc/rc.d/rc.local something like chmod 0666 /dev/snd/* In /usr/share/doc/udev-058/writing_udev_rules/index.html I learned more than I ever wanted to know, and found the ostensible culprit in /etc/udev/rules.d/50-udev.rules : # alsa devices KERNEL=="controlC[0-9]*", NAME="snd/%k" KERNEL=="hw[CD0-9]*", NAME="snd/%k" KERNEL=="pcm[CD0-9cp]*", NAME="snd/%k" KERNEL=="midi[CD0-9]*", NAME="snd/%k" KERNEL=="timer", NAME="snd/%k" KERNEL=="seq", NAME="snd/%k" Eureka! No MODE is specified, so it defaults to 0600. I copied these lines to 40-local.rules with a MODE specified: # modifications by dad # alsa devices KERNEL=="controlC[0-9]*", NAME="snd/%k", MODE="0666" KERNEL=="hw[CD0-9]*", NAME="snd/%k", MODE="0666" KERNEL=="pcm[CD0-9cp]*", NAME="snd/%k", MODE="0666" KERNEL=="midi[CD0-9]*", NAME="snd/%k", MODE="0666" KERNEL=="timer", NAME="snd/%k", MODE="0666" KERNEL=="seq", NAME="snd/%k", MODE="0666" and rebooted. To my surprise and dismay, there was no change. The permissions in /dev/snd/* remained 0600. Then I discovered the command 'udevstart' with the admonition "Make sure you remember to run" it. When I ran it, the permissions did change to 0666. But after another reboot the permissions reverted to 0600. Evidently, udevstart is NOT being executed at bootup, despite the line in /etc/rc.d/rc.sysinit: [ -x /sbin/start_udev ] && /sbin/start_udev and the line in /sbin/start_udev: /sbin/udevstart So, what IS the RIGHT WAY to fix the /dev/snd/* permissions? All the above is from a new x86_64 machine. On my other i386 machines the situation is different. The permissions are: # ll /dev/snd total 0 crw------- 1 dad root 116, 0 Aug 29 17:30 controlC0 crw------- 1 dad root 116, 24 Aug 29 17:30 pcmC0D0c crw------- 1 dad root 116, 16 Aug 29 17:30 pcmC0D0p crw------- 1 dad root 116, 25 Aug 29 17:30 pcmC0D1c crw------- 1 dad root 116, 18 Aug 29 17:30 pcmC0D2p crw------- 1 dad root 116, 1 Aug 29 17:30 seq crw------- 1 dad root 116, 33 Aug 29 17:30 timer These permissions are also clearly wrong, although as user dad the alsa sound system works for me (but not for anyone else). How these files came to owned by 'dad' is a total mystery. But the strangest part is that when I create /etc/udev/rules.d/40-local.rules with MODE="0666" added and run udevstart, NOTHING HAPPENS. The /dev/snd/* permissions remain as above. I hope someone more experienced can explain this wierd behaviour.
Does the latest udev update fix your issues?
I have udev-071-0.FC4.2 installed on five different, but similarly provisioned, machines. I cannot tell if this version fixes my problem because the results are DIFFERENT, despite having identical files in /etc/udev/rules.d on all machines. # ll /etc/udev/rules.d total 32 -rw-r--r-- 1 root root 146 Apr 13 2005 10-wacom.rules -rw-r--r-- 1 root root 12380 Jan 31 11:09 50-udev.rules -rw-r--r-- 1 root root 318 Feb 7 09:50 51-vdr.rules -rw-r--r-- 1 root root 307 Jan 31 11:09 hotplug.rules A relevant line in 50-udev.rules would seem to be: KERNEL=="snd/*", MODE="0660" However, NONE of the systems have the 0660 permissions that are dictated by this rule, but the first and fourth do have the 0666 permissions that I consider correct. I have been unable to find why this is so. 1) On a 32 bit Athlon system after a reboot I see # ll /dev/snd total 0 crw-rw-rw- 1 dad root 116, 0 Feb 17 07:30 controlC0 crw-rw-rw- 1 dad root 116, 24 Feb 17 07:30 pcmC0D0c crw-rw-rw- 1 dad root 116, 16 Feb 17 07:30 pcmC0D0p crw-rw-rw- 1 dad root 116, 25 Feb 17 07:30 pcmC0D1c crw-rw-rw- 1 dad root 116, 18 Feb 17 07:30 pcmC0D2p crw-rw-rw- 1 dad root 116, 1 Feb 17 07:30 seq crw-rw-rw- 1 dad root 116, 33 Feb 17 07:30 timer 2) On a Pentium Mobile 4 laptop I see # ll /dev/snd total 0 crw------- 1 dad root 116, 0 Feb 17 06:34 controlC0 crw------- 1 dad root 116, 32 Feb 17 06:34 controlC1 crw------- 1 dad root 116, 24 Feb 17 06:34 pcmC0D0c crw------- 1 dad root 116, 16 Feb 17 06:34 pcmC0D0p crw------- 1 dad root 116, 25 Feb 17 06:34 pcmC0D1c crw------- 1 dad root 116, 56 Feb 17 06:34 pcmC1D0c crw------- 1 dad root 116, 48 Feb 17 06:34 pcmC1D0p crw------- 1 dad root 116, 1 Feb 17 06:34 seq crw------- 1 dad root 116, 33 Feb 17 06:34 timer 3) On a headless Pentium 200, accessed solely thru vncviewer I see # ll /dev/snd total 0 crw------- 1 root root 116, 0 Feb 17 06:59 controlC0 crw------- 1 root root 116, 4 Feb 17 06:59 hwC0D0 crw------- 1 root root 116, 8 Feb 17 06:59 midiC0D0 crw------- 1 root root 116, 24 Feb 17 06:59 pcmC0D0c crw------- 1 root root 116, 16 Feb 17 06:59 pcmC0D0p crw------- 1 root root 116, 1 Feb 17 06:59 seq crw------- 1 root root 116, 33 Feb 17 06:59 timer 4) On a 64 bit Athlon system I see # ll /dev/snd total 0 crw-rw-rw- 1 dad root 116, 0 Feb 15 17:30 controlC0 crw-rw-rw- 1 dad root 116, 24 Feb 15 17:30 pcmC0D0c crw-rw-rw- 1 dad root 116, 16 Feb 15 17:30 pcmC0D0p crw-rw-rw- 1 dad root 116, 25 Feb 15 17:30 pcmC0D1c crw-rw-rw- 1 dad root 116, 18 Feb 15 17:30 pcmC0D2p crw-rw-rw- 1 dad root 116, 1 Feb 15 17:30 seq crw-rw-rw- 1 dad root 116, 33 Feb 15 17:30 timer Note that the permissions on the second (laptop) and third (headless) machines preclude use of the sound system by users other than the first to log in. This is totally unacceptable. Someone seems to have forgotten that Linux is, first and foremost, a multiuser system. It is NOT Windows. I deplore the mindset that seems to be driving Linux to be more like Windows. I've modified /etc/udev/udev.conf on the first and second machines: # The syslog(3) priority: "err", "info", or the numerical value. ## udev_log="err" # Modified by dad udev_log="info" This produces voluminous "udevd" lines in /var/log/messages, but none mention any activity related to /dev/snd, so I can't see any evidence that the rules are being utilized, or any clue why the permissions come out as they do. I am totally baffled and frustrated by this overly complex and confusing udev system.
The console devices (including sound) are owned by the console user. This is done by pam_console. The first user who logs in on a console (or X) gets the console devices. To see, what device nodes are changed look in /etc/security/console.perms*
Thanks, Harald, for revealing that the permissions for the sound devices and other console devices are specified in /etc/security/console.perms.d/50-default.perms and not in /etc/udev/rules.d/50-udev.rules, as I had naively surmised. Imagine my surprise in learning that all the information in the latter file related to MODE is WRONG, IRRELEVANT and MISLEADING, because the pam system overrides and replaces anything in that file. Of course, this leaves a fairly serious bug that needs to be fixed. Here are three possible methods. 1) Edit all udev documentation and the relevant rules files to remove all reference to MODE but, I suppose, only for those devices that the pam folks have chosen to override. 2) Add a comment in the 50-udev.rules file such as "MODE statements for certain devices are ignored because the pam system overrides them. We leave it as an exercise to find which devices are so affected." 3) File a bugzilla complaint that the pam system is a giant bug that should be removed entirely. Thanks for your attention, and patience.