Bug 167248

Summary: Bad permissions in /dev/snd/ block alsa sound
Product: [Fedora] Fedora Reporter: David A. De Graaf <dad>
Component: udevAssignee: Harald Hoyer <harald>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-01 05:59:08 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description David A. De Graaf 2005-08-31 17:25:51 EDT
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:

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.

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

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:

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

I hope someone more experienced can explain this wierd behaviour.
Comment 1 Harald Hoyer 2005-09-01 05:59:08 EDT
$ fgrep -2 snd /etc/security/console.perms.d/50-default.perms
        /dev/mixer* /dev/sequencer \
        /dev/sound/* /dev/beep \
<cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*

$ rpm -qf /etc/security/console.perms.d/50-default.perms

/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
Comment 2 David A. De Graaf 2005-09-01 13:35:57 EDT
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?
Comment 3 Harald Hoyer 2005-09-02 03:37:18 EDT
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.