Bug 167318 - Bad permissions in /dev/snd/ block alsa sound
Bad permissions in /dev/snd/ block alsa sound
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-01 11:38 EDT by David A. De Graaf
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 08:42:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David A. De Graaf 2005-09-01 11:38:01 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:
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.
Comment 1 Harald Hoyer 2006-02-15 06:33:42 EST
Does the latest udev update fix your issues?
Comment 2 David A. De Graaf 2006-02-17 13:52:52 EST
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.
Comment 3 Harald Hoyer 2006-02-21 08:42:19 EST
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*
Comment 4 David A. De Graaf 2006-02-21 13:59:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.