Bug 167248
| Summary: | Bad permissions in /dev/snd/ block alsa sound | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David A. De Graaf <dad> |
| Component: | udev | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-01 09:59:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
$ fgrep -2 snd /etc/security/console.perms.d/50-default.perms
/dev/mixer* /dev/sequencer \
/dev/sound/* /dev/beep \
/dev/snd/*
<cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*
<pilot>=/dev/pilot
$ rpm -qf /etc/security/console.perms.d/50-default.perms
pam-0.79-8
/dev/snd/* gets the ownership of the first logged in console user, maybe this is
your problem.
$ ll /dev/snd/*
crw------- 1 harald root 116, 0 29. Aug 08:03 /dev/snd/controlC0
crw------- 1 harald root 116, 32 29. Aug 08:03 /dev/snd/controlC1
crw------- 1 harald root 116, 64 29. Aug 08:03 /dev/snd/controlC2
crw------- 1 harald root 116, 4 29. Aug 08:03 /dev/snd/hwC0D0
crw------- 1 harald root 116, 8 29. Aug 08:03 /dev/snd/midiC0D0
....
You're absolutely right about the first logged in user getting ownership.
This, if I may say so, is an incredibly defective design. Very Windows-esque.
Whatever happened to the notion that Linux is a multiuser system? How is the
second, or third, user supposed to hear sounds?
There are (a few) reasons that more than one sound should play concurrently.
I can do it myself in two different windows. But when another user does this
$ aplay /usr/share/sounds/*.wav
ALSA lib pcm_dmix.c:782:(snd_pcm_dmix_open) unable to create IPC semaphore
aplay: main:533: audio open error: Permission denied
even with /dev/snd/* permissions set to 0666.
So apparently there are more impediments to progress than those permissions;
the semaphore system, too.
I think it's a bug that multiple users cannot use the sound system concurrently.
How can it be fixed?
The one console user owns all console devices. You do not want to let remote users play sounds, which only the console user can hear. For more information and to express your concerns, please subscribe to the fedora-list and discuss it there. http://www.redhat.com/mailman/listinfo/fedora-list |
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.