Bug 292201 - ALSA mixer only usable as root
ALSA mixer only usable as root
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-15 17:13 EDT by Joachim Frieben
Modified: 2013-03-05 22:51 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-12 12:30:39 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)
scsconfig.log for CS4236 on-board audio device of PR440FX (34.08 KB, text/plain)
2007-09-20 05:22 EDT, Joachim Frieben
no flags Details
scsconfig.log from my system-configure-soundcard (32.23 KB, application/octet-stream)
2007-10-07 23:54 EDT, Scott Robbins
no flags Details
My /var/lib/hal/acl-list (1.80 KB, text/plain)
2007-11-15 18:34 EST, Hans Otten
no flags Details

  None (edit)
Description Joachim Frieben 2007-09-15 17:13:37 EDT
Description of problem:
For a fully updated "rawhide" system, launching "alsamixer" aborts with
an error message:

 "alsamixer: function snd_ctl_open failed for default: No such device".

Version-Release number of selected component (if applicable):
alsa-utils-1.0.14-2.fc8

How reproducible:
Always.

Steps to Reproduce:
1. Launch "alsamixer" from the shell.
  
Actual results:
"alsamixer" aborts issuing "alsamixer: function snd_ctl_open failed for
default: No such device".

Expected results:
Mixer panel is opened, and settings can be changed.

Additional info:
After logging in as root, the mixer panel is opened, and it is actually
possible to modify the settings.
Running "alsamixer" as an ordinary user was possible for both "Fedora
Core 6" and "Fedora 7".
Comment 1 Martin Stransky 2007-09-19 05:30:23 EDT
Aha. Can you please run system-config-soundcard, create /root/scsconfig.log and
attach it here?
Comment 2 Joachim Frieben 2007-09-20 05:22:06 EDT
Created attachment 200581 [details]
scsconfig.log for CS4236 on-board audio device of PR440FX

(In reply to comment #1)
> Aha. Can you please run system-config-soundcard, create /root/scsconfig.log
and
> attach it here?
Comment 3 Scott Robbins 2007-10-07 23:23:54 EDT
I've had this problem on three test installs now.  Trying to simplify 
troubleshooting, I did the following.  
Installed from the 7.92 liveCD.  After booting up as normal user, the sound 
icon in the upper right was fine and I had sound. 

I then ran yum -y update.  After rebooting, there was a small red X by the 
sound icon and sound no longer worked.  However, running system-config-
soundcard, which requires root permissions, worked.  

This may not be specific to 7.92 as, while trying to solve the issue, I ran 
across http://ditesh.gathani.org/blog/2007/09/07/much-ado-about-nothing/

(I receive the same error messages as mentioned in that link, but his solutions 
didn't work for me.)

I can post any required logs, but it won't be till tomorrow evening.

Thanks for your work on this.  
Comment 4 Scott Robbins 2007-10-07 23:54:38 EDT
Created attachment 219011 [details]
scsconfig.log from my system-configure-soundcard

I'm adding my own scsconfig.log in case it helps.  Thank you again.
Comment 5 Scott Robbins 2007-10-09 13:20:37 EDT
This seems to have been partially fixed by the latest kernel update (2.6.23-
0.224.rc9.git6.fc8). By partially, I mean that sound will now work for regular 
user if one changes the permissions for /dev/dsp and /dev/snd.  Until today's 
update, doing a chmod on those two wouldn't solve the problem.  (Before the 
problem arose, no chmod-ing was necessary.)
Comment 6 Scott Robbins 2007-10-09 18:59:45 EDT
Ok, on a second machine, it seems as if by adding 

<sound>=/dev/dsp* /dev/snd/*  to the top part of
/etc/security/cosole.perms.d/50-default.perms and 
<console> 0666 <sound>       0600 root

to the lower part, I can get sound working as normal user without the upgrade. 
I know that doing a chmod on those two on another machine didn't fix it before
the upgrade.  

On this machine, now I don't remember if I even tried doing that.  

It's possible, that after trying that and having it do nothing on the other
machine, I didn't bother. 



Comment 7 Joachim Frieben 2007-10-10 04:33:13 EDT
Btw, the sound subsystem is not the only one which is affected by the current
permission problems. I am also unable to access the floppy drive as an ordinary
user using 'mtools'. I even have to be 'root' in order to be able to read from a
diskette.
Comment 8 Pavel Roskin 2007-10-19 12:49:43 EDT
I understand that the audio should be available to the locally logged in user,
but it isn't.  I'm using icewm as window manager.

$ id
uid=500(proski) gid=500(proski) groups=10(wheel),14(uucp),500(proski),501(sbox)

$ ls -al /dev/snd/
total 0
drwxr-xr-x  2 root root     220 Oct 19 11:57 .
drwxr-xr-x 12 root root    4420 Oct 19 11:57 ..
crw-rw----  1 root root 116,  0 Oct 19 11:57 controlC0
crw-rw----  1 root root 116, 24 Oct 19 11:57 pcmC0D0c
crw-rw----  1 root root 116, 16 Oct 19 11:57 pcmC0D0p
crw-rw----  1 root root 116, 25 Oct 19 11:57 pcmC0D1c
crw-rw----  1 root root 116, 26 Oct 19 11:57 pcmC0D2c
crw-rw----  1 root root 116, 27 Oct 19 11:57 pcmC0D3c
crw-rw----  1 root root 116, 20 Oct 19 11:57 pcmC0D4p
crw-rw----  1 root root 116,  1 Oct 19 11:57 seq
crw-rw----  1 root root 116, 33 Oct 19 11:57 timer

I haven't changed anything in PAM or udev configuration.  I think PAM should be
responsible, not alsa-utils, as the later correctly refuses to work with
insufficient permissions.
Comment 9 Nils Philippsen 2007-11-08 10:54:17 EST
Same here on a F7 to F8 upgrade x86_64 machine. I see that no devices usually
owned by the logged in user (e.g. floppy devices) are owned by the logged in
user or have proper ACLs set up.

In contrast, a machine with a fresh F8 installation has this:

nils@gibraltar:~> ls -al /dev/snd/
total 0
drwxr-xr-x   2 root root    180 2007-11-02 11:46 .
drwxr-xr-x  15 root root   4640 2007-11-08 15:48 ..
crw-rw----+  1 root root 116, 8 2007-11-02 11:46 controlC0
crw-rw----+  1 root root 116, 7 2007-11-02 11:46 hwC0D0
crw-rw----+  1 root root 116, 6 2007-11-02 11:46 pcmC0D0c
crw-rw----+  1 root root 116, 5 2007-11-02 11:46 pcmC0D0p
crw-rw----+  1 root root 116, 4 2007-11-02 11:46 pcmC0D1p
crw-rw----+  1 root root 116, 3 2007-11-02 11:46 seq
crw-rw----+  1 root root 116, 2 2007-11-02 11:46 timer

E.g. the ACLS on the control file are:

nils@gibraltar:~> getfacl /dev/snd/controlC0 
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0
# owner: root
# group: root
user::rw-
user:gdm:rw-
user:nils:rw-
group::rw-
mask::rw-
other::---

The non-working machine looks similar to comment #8, with no ACLs on the files.

I've changed the product version to f8 FWIW and bumped severity (system without
sound is no fun). I think that this is not a problem specific to the sound
system as floppy devices are affected as well.
Comment 10 Nils Philippsen 2007-11-08 10:59:16 EST
NB: This is the non-working machine (upgrade):

root@wombat:~> find /dev -type c -o -type b | xargs ls -l | grep +
root@wombat:~> 

---> no ACLs added

And this is the working machine (fresh install):


[root@gibraltar ~]# find /dev -type c -o -type b | xargs ls -l | grep +
crw-rw----+ 1 root root  14,  12 2007-11-02 11:46 /dev/adsp
crw-rw----+ 1 root root  14,   4 2007-11-02 11:46 /dev/audio
crw-rw-r--+ 1 root root 189, 809 2007-11-08 14:06 /dev/bus/usb/007/042
crw-rw----+ 1 root root  14,   3 2007-11-02 11:46 /dev/dsp
crw-rw----+ 1 root root  14,   0 2007-11-02 11:46 /dev/mixer
crw-rw----+ 1 root root  14,   1 2007-11-02 11:46 /dev/sequencer
crw-rw----+ 1 root root  14,   8 2007-11-02 11:46 /dev/sequencer2
crw-rw----+ 1 root root 116,   8 2007-11-02 11:46 /dev/snd/controlC0
crw-rw----+ 1 root root 116,   7 2007-11-02 11:46 /dev/snd/hwC0D0
crw-rw----+ 1 root root 116,   6 2007-11-02 11:46 /dev/snd/pcmC0D0c
crw-rw----+ 1 root root 116,   5 2007-11-02 11:46 /dev/snd/pcmC0D0p
crw-rw----+ 1 root root 116,   4 2007-11-02 11:46 /dev/snd/pcmC0D1p
crw-rw----+ 1 root root 116,   3 2007-11-02 11:46 /dev/snd/seq
crw-rw----+ 1 root root 116,   2 2007-11-02 11:46 /dev/snd/timer
brw-rw----+ 1 root disk  11,   0 2007-11-02 11:46 /dev/sr0
[root@gibraltar ~]#

---> ACLs for the logged in user added, not only to the sound devices but also
to the fingerprint reader (/dev/bus/usb/007/042) and the optical drive (/dev/sr0)
Comment 11 Nils Philippsen 2007-11-08 11:15:43 EST
Changing the component to hal as this seems more appropriate.
Comment 12 Nils Philippsen 2007-11-08 11:18:34 EST
Versions here on both machines are:

hal-0.5.10-1.fc8
hal-info-20071030-1.fc8
Comment 13 Nils Philippsen 2007-11-08 12:42:09 EST
After some digging in /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
and playing with /usr/libexec/hal-acl-tool I found that /var/lib/hal/acl-list
contained binary garbage (why ever):

root@wombat:~> cat /var/lib/hal/acl-list 
��G�3"�G�3selinuxroot@wombat:~> 

After removing the file and restarting haldaemon, everything was back in working
order again.

Perhaps hald or hal-acl-tool should detect bogus contents in the file and in
that case recreate it.
Comment 14 Scott Robbins 2007-11-10 00:35:05 EST
I've also found (through a post on Fedora forums) that in my particular case, I 
can resolve the non-root issue by enabling ConsoleKit (which is enabled by 
default, so the newcomer would probably not have run into this issue.)

I have it disabled--however, if I enable it, I can remove the lines I mentioned 
from console.perms.d/50-default.perms and sound will work for all users.  If I 
don't enable ConsoleKit, I have to have those lines for sound to work (for non-
root users.)

Comment 15 Nils Philippsen 2007-11-10 06:52:34 EST
Note that ConsoleKit is a core service that AFAIK is supposed to replace the
/etc/security/console.perms* mechanism, i.e. things are not expected to work
without it running.
Comment 16 Scott Robbins 2007-11-10 08:19:18 EST
Noted with thanks.  However, this wasn't a problem till the updates (back when 
Fedora 8 was 7.92)  

Alas, poorly documented.  I think that many people wind up finding the link 
below in trying to determine what services they can turn off.  

http://www.mjmwired.net/resources/mjm-services-f7.html

There is no man page that I can find in Fedora for consolekit and the README in 
/usr/share/doc doesn't really indicate this.  

Again many thanks for the information.  As the problem is frequently being 
mentioned on Fedora forums, I will pass this along.  
Comment 17 Leo Canale 2007-11-11 12:53:34 EST
Sorry to crash the party I filed this before I found this one!
https://bugzilla.redhat.com/show_bug.cgi?id=370821
I have ConsoleKit running and I did:
[root@freshy-desktop ~]# cat /var/lib/hal/acl-list 
/dev/sequencer  /org/freedesktop/Hal/devices/computer_oss_sequencer     u       42
/dev/sequencer2 /org/freedesktop/Hal/devices/computer_oss_sequencer_0   u       42
/dev/snd/seq    /org/freedesktop/Hal/devices/computer_alsa_sequencer    u       42
/dev/snd/timer  /org/freedesktop/Hal/devices/computer_alsa_timer        u       42
 But still no go!
 I still cannot see any sound card device  as "user" in my sound card
Preferences gui
 I can how-ever see as "root" this message when I execute gnome-sound-properties
"Unable to start the settings manager 'gnome-settings-daemon'.
Without the GNOME settings manager running, some preferences may not take
effect. This could indicate a problem with Bonobo, or a non-GNOME (e.g. KDE)
settings manager may already be active and conflicting with the GNOME settings
manager." and when I click OK I see the preferences gui with the correct sound
card and all!
Comment 18 Leo Canale 2007-11-11 13:01:38 EST
Here is some additional info:
[engwnbie@freshy-desktop ~]$ aplay -l
aplay: device_list:205: no soundcards found...
[engwnbie@freshy-desktop ~]$ su
Password: 
[root@freshy-desktop engwnbie]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Live [Dell Sound Blaster Live!], device 0: emu10k1x [EMU10K1X Front]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Live [Dell Sound Blaster Live!], device 1: emu10k1x [EMU10K1X Rear]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Live [Dell Sound Blaster Live!], device 2: emu10k1x [EMU10K1X Center/LFE]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
[root@freshy-desktop engwnbie]# 
Comment 19 David Zeuthen 2007-11-12 12:30:39 EST
(In reply to comment #14)
> I've also found (through a post on Fedora forums) that in my particular case, I 
> can resolve the non-root issue by enabling ConsoleKit (which is enabled by 
> default, so the newcomer would probably not have run into this issue.)

This is like the 10th bug like this.. In F9 and onwards ConsoleKit I'll make it
impossible to disable ConsoleKit.
Comment 20 Joachim Frieben 2007-11-12 13:05:04 EST
I was hit by this issue after a minimum F7 install [everything unchecked
except for yum and dhclient] from DVD and updating and downloading the
rest of the system over the network from the "rawhide" tree. At the end
of this procedure, I found myself unable to control the audio devices or
access the floppy disk drive as an ordinary user. I hadn't disabled any
services deliberately. Why is this report that I had opened upon this
experience closed as "NOTABUG" then?
Comment 21 Nils Philippsen 2007-11-12 15:10:07 EST
Joachim, can you check the contents of /var/lib/hal/acl-list on your machine please?
Comment 22 Joachim Frieben 2007-11-12 16:00:45 EST
After repeating the same procedure starting with an F8T3 minimum install,
I didn't encounter this problem anymore. I will try the F7 one prior to
a fresh F8 install one of these days.
Comment 23 Joachim Frieben 2007-11-14 02:00:19 EST
I have installed current "rawhide" starting again from a minimum F7 install,
albeit on a different system since the original one has been dismantled.
The device permissions are correct now. I can access the floppy drive and
use the ALSA mixer. The change of hardware should have no impact.
This result seems to suggest that some intermediate package version from
the "rawhide" tree messed things up.
Comment 24 Scott Robbins 2007-11-15 06:20:17 EST
I hadn't gotten around to enabling ConsoleKit at startup.  After updating 
Fedora 8 last night (14 November, 2007) I find that editing console.perms.d/50-
default-perms is no longer sufficient and that it is now  definitely necessary 
to enable ConsoleKit.  (The importance of ConsoleKit has been mentioned in this 
thread, I'm simply adding this information in case people find this thread in a 
search for solutions to their sound problems.)

@davidz--rather than making it impossible to disable ConsoleKit, wouldn't it be 
far less effort to have a few lines of documentation somewhere, perhaps even a 
brief man page?  It could basically direct them to the rather insufficient 
README, but at least add a note that this is one service which should not be 
disabled, whether or not the user is running Gnome.   (The same probably goes 
for the avahi-daemon man page, which doesn't really indicate that it affects 
more than DNS.)

Comment 25 David Zeuthen 2007-11-15 11:34:50 EST
(In reply to comment #24)
> @davidz--rather than making it impossible to disable ConsoleKit, wouldn't it be 
> far less effort 

No, I've spent 10+ hours this past month of dealing with users who think they
know better, go and disable things they don't know about and then expect things
to work. Sorry.
Comment 26 Nils Philippsen 2007-11-15 11:54:18 EST
(In reply to comment #25)
> No, I've spent 10+ hours this past month of dealing with users who think they
> know better, go and disable things they don't know about and then expect things
> to work. Sorry.

That's always the case with new things that happen to be essential. You're aware
that you can hide essential services from the uninitiated user in s-c-services
with "# hide: true" in the chkconfig preamble of the init file?
Comment 27 David Zeuthen 2007-11-15 12:02:44 EST
(In reply to comment #26)
> (In reply to comment #25)
> > No, I've spent 10+ hours this past month of dealing with users who think they
> > know better, go and disable things they don't know about and then expect things
> > to work. Sorry.
> 
> That's always the case with new things that happen to be essential. You're aware
> that you can hide essential services from the uninitiated user in s-c-services
> with "# hide: true" in the chkconfig preamble of the init file?

I wasn't aware but the decision to move from initscripts to activation-on-demand
also has to do with making the boot process faster and the system more robust by
making the whole dependency problem that initscripts inflict on us go away.

Besides, I bet the "optimizers" just use chkconfig(8) instead of s-c-services.


Comment 28 Nils Philippsen 2007-11-15 12:14:41 EST
(In reply to comment #27)
> I wasn't aware but the decision to move from initscripts to
> activation-on-demand also has to do with making the boot process faster and
> the system more robust by making the whole dependency problem that initscripts
> inflict on us go away.

Regardless of that, you'll still have to hide it from s-c-services eventually as
admins should have the ability to enable and disable on-demand activated
services just as SysVinit or xinetd services.

> Besides, I bet the "optimizers" just use chkconfig(8) instead of s-c-services.

There's that. But even if you move away from SysVinit, this bunch will find a
way to somehow make it not run ;-).
Comment 29 David Zeuthen 2007-11-15 12:28:45 EST
(In reply to comment #28)
> Regardless of that, you'll still have to hide it from s-c-services eventually as
> admins should have the ability to enable and disable on-demand activated
> services just as SysVinit or xinetd services.

Disagree. Here's two reasons

 - It's just silly to turn this service off; it's not like it's using a lot
   of resources

 - By making it mandatory, code higher in the stack don't have to put in
   silly checks.

Remember. Options leads to madness [1]. Like the current situation where the
"optimizers" turn critical services off and expect their system to work. It's
non-sense and increases the load on the support infrastructure for the distro.

[1] : Cutting too many options like GNOME did in the early 2.x days is bad too.
It's about finding a happy balance, a happy medium. Pretty much like everything
else in life.

> There's that. But even if you move away from SysVinit, this bunch will find a
> way to somehow make it not run ;-).

They can uninstall the package if they don't need it. It's fine, it's not needed
for a minimal install.

Comment 30 Scott Robbins 2007-11-15 18:14:02 EST
@davidz and everyone else, I wasn't trying to be a troll here.  David Z., thank 
you for taking the time to explain why you feel the best course would be to 
make it difficult to disable ConsoleKit.  We users tend to forget how often you 
developers are blamed for things that are the fault of we users. 

Believe it or not, we do appreciate all the work you folks do for our benefit. 
Comment 31 Hans Otten 2007-11-15 18:34:37 EST
Created attachment 260581 [details]
My /var/lib/hal/acl-list
Comment 32 Hans Otten 2007-11-15 18:40:27 EST
Comment on attachment 260581 [details]
My /var/lib/hal/acl-list

I have the same problem. I did a clean install of Fedora 8 and my sound card
doesn't work either, although when I run "Soundcard Detection" it does. I
*haven't* disabled ConsoleKit, so that's not the source of the problem. Funny
thing is that I also have a USB web-cam which has a microphone, and when I plug
that in ALSA and the PulseAudio stuff *do* see it (as does "Soundcard
Detection" BTW).

In the /dev directory I see that the web-cam related nodes have an ACL setup so
the logged in user can access the device. The sound card related nodes do not.
My sound card BTW is a [Dell Sound Blaster Live!], same as Leo Canale in
comments #17 and #18.

I'm guessing hald is responsible for setting up the ACL's and maybe it's making
a booboo somewhere? I'll try to see if I can get some more logging out of hald
later (it's late).
Comment 33 Hans Otten 2007-11-15 18:59:14 EST
(In reply to comment #32)

It looks like I'm having exactly the same problem as Leo Canale in bug #370821.
Sorry for the inconvenience.
Comment 34 Nils Philippsen 2007-11-16 09:07:23 EST
(In reply to comment #29)
> (In reply to comment #28)
> > Regardless of that, you'll still have to hide it from s-c-services eventually as
> > admins should have the ability to enable and disable on-demand activated
> > services just as SysVinit or xinetd services.
> 
> Disagree. Here's two reasons
> 
>  - It's just silly to turn this service off; it's not like it's using a lot
>    of resources
> 
>  - By making it mandatory, code higher in the stack don't have to put in
>    silly checks.

I'm totally with you as far as ConsoleKit is concerned. Let me clarify what I
meant: Even with on-demand-activated services, in many cases letting an admin
expressly disable them is sensible. A tool for configuring this should be able
to do the right thing with exceptions like ConsoleKit, i.e. hide them from the
user. The notion of a service that is so important that it shouldn't be disabled
isn't new if we talk about s-c-services, e.g. xfs was hidden so users couldn't
mess with it.
Comment 35 Leo Canale 2007-11-17 19:00:41 EST
(In reply to comment #33)
> (In reply to comment #32)
> 
> It looks like I'm having exactly the same problem as Leo Canale in
gnome-volume-control.
> Sorry for the inconvenience.

Hans are you able to change your Display Settings? On my 2 machines that I have
running F8 I have very little access to resources on both! If I log in as "root"
on my Machine then everything is fine other than PulseAudio did not get
configured with all the bit's that were needed. So my issues are that at start
up the right amount of rights are set for the user. ie I cannot change the
Display setting from what the system decided that they should be! As normal user
sound devices, floppy drive and so on. If I change rights or change all the
other bits that are out there I can get sound to work. But that is not the right
solution. Both these 2 boxes have had Fedora Core 4 and on and they have never
had any issues even when others were having display and sound issues, I never
had them on these boxes. In short I want to help get these problems resolved
properly so it will help everyone! I'm not interested in changing all kinds of
settings and never get to the root of the problem "so to speak" My problems are
simple I think. The normal user is not getting configured right from the first
place. I wish I was able to help fix the problem, but I'm not that kind of
engineer. I'm an electrical eng. Not software! David Z sorry not criticizing
you! You are right more should read and understand what they read from all the
"guides" that are out there! But we would not be here complaining if we did not
have a problem. But you know how things can snow ball when things don't work. My
first thing that I noticed was the little speaker thingy had a red x on it. So I
too thought that my problem is due to sound. But thats not the root of the
problem. There is some problem with access rights. Sorry to go on here! But how
can we help get to the root of this problem? Leo.
Comment 36 Leo Canale 2007-11-18 12:49:10 EST
For curiosity I downloaded the live CD and tested on my fist machine with Sound
Blaster Card. I get the same problem as  what I get from the installed DVD
version no difference. Then I tried the live CD on another machine (ubuntu
installed) with the Intel card, and everything is fine here is the output.
[fedora@localhost ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel
82801DB-ICH4 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
[fedora@localhost ~]$ find /dev -type c -o -type b | xargs ls -l | grep +
crw-rw----+ 1 root   root    14,  12 2007-11-18 17:17 /dev/adsp
crw-rw----+ 1 root   root    14,   4 2007-11-18 17:17 /dev/audio
crw-rw----+ 1 root   root    14,   3 2007-11-18 17:17 /dev/dsp
crw-rw----+ 1 root   root    14,   0 2007-11-18 17:17 /dev/mixer
crw-rw----+ 1 root   root    14,   1 2007-11-18 17:17 /dev/sequencer
crw-rw----+ 1 root   root    14,   8 2007-11-18 17:17 /dev/sequencer2
crw-rw----+ 1 root   root   116,  10 2007-11-18 17:17 /dev/snd/controlC0
crw-rw----+ 1 root   root   116,   9 2007-11-18 17:17 /dev/snd/pcmC0D0c
crw-rw----+ 1 root   root   116,   8 2007-11-18 17:17 /dev/snd/pcmC0D0p
crw-rw----+ 1 root   root   116,   7 2007-11-18 17:17 /dev/snd/pcmC0D1c
crw-rw----+ 1 root   root   116,   6 2007-11-18 17:17 /dev/snd/pcmC0D2c
crw-rw----+ 1 root   root   116,   5 2007-11-18 17:17 /dev/snd/pcmC0D3c
crw-rw----+ 1 root   root   116,   4 2007-11-18 17:17 /dev/snd/pcmC0D4p
crw-rw----+ 1 root   root   116,   3 2007-11-18 17:17 /dev/snd/seq
crw-rw----+ 1 root   root   116,   2 2007-11-18 17:17 /dev/snd/timer
brw-rw----+ 1 root   disk    11,   0 2007-11-18 12:16 /dev/sr0
[fedora@localhost ~]$ 

Even the Live CD has the same problem, when boots and find what ever hardware it
does not like it sets access rights wrong!
Comment 37 Scott Robbins 2007-11-18 13:52:35 EST
Now I'm finding that I have to enable ConsoleKit and, in addition, edit the 50-
defaults-perm file for sound to work as non-root user.  I will grant this might 
just be my machine, but right now, I don't have the time or diskspace to do a 
fresh install and see what happens.
Comment 38 Leo Canale 2007-11-18 16:25:32 EST
(In reply to comment #37)
> Now I'm finding that I have to enable ConsoleKit and, in addition, edit the 50-
> defaults-perm file for sound to work as non-root user.  I will grant this might 
> just be my machine, but right now, I don't have the time or diskspace to do a 
> fresh install and see what happens.
> 

Read above it's not just you, and it has not only to do with ConsoleKit. I have
never disabled anything on any of my installations. I always do a fresh install
and never have had problems until F8! Just do a search on this bugzilla on F8
only and there are lot's of people having this problem, they just don't know it
yet that it is the same thing! If I log on as root everything works!. I know I'm
not supposed to do that. Just for testing. I love fedora because I used to
administer a Sun network 20 + years ago and Fedora is the closest thing to that
to me. I tried to install ubuntu on my server that has a fake raid 1 set up and
I have to do all kind of messing around to getting it to work. So I'm in the
middle of re-installing Fedora on it. It has no problem to recognize the raid,
and I'm will to wait until they fix this issue. This is the only time I have had
issues with Fedora since FC2!
Comment 39 Scott Robbins 2007-11-21 11:13:04 EST
FWIW, the fellow who maintains the mjmwired pages I mentioned in one of my 
early posts on this, has a page for Fedora 8 services now.  He's updated it to 
mention some of the problems encountered when disabling ConsoleKit.

Comment 40 kmike 2008-02-15 09:32:36 EST
(In reply to comment #19)
> 
> This is like the 10th bug like this.. In F9 and onwards ConsoleKit I'll make it
> impossible to disable ConsoleKit.
> 

What about the numerous reports where ConsoleKit is running but the audio
permissions are still wrong? I just upgraded from F7 to F8, ConsoleKit is
running but no audio. Apart from the latest reports here, Google shows there are
many many similar issues. E.g.
http://lindesk.com/2007/11/sound-issue-in-fedora-8/ (check comments)

# chkconfig --list ConsoleKit
ConsoleKit      0:off   1:off   2:on    3:on    4:on    5:on    6:off
# /etc/init.d/ConsoleKit status
console-kit-daemon (pid 1868) is running...

# ls -l /dev/snd
total 0
crw-rw----+ 1 root root 116, 10 Feb 14 23:01 controlC0
crw-rw----+ 1 root root 116, 13 Feb 14 23:01 controlC1
crw-rw----+ 1 root root 116,  9 Feb 14 23:01 pcmC0D0c
crw-rw----+ 1 root root 116,  8 Feb 14 23:01 pcmC0D0p
crw-rw----+ 1 root root 116,  7 Feb 14 23:01 pcmC0D1c
crw-rw----+ 1 root root 116,  6 Feb 14 23:01 pcmC0D2c
crw-rw----+ 1 root root 116,  5 Feb 14 23:01 pcmC0D3c
crw-rw----+ 1 root root 116,  4 Feb 14 23:01 pcmC0D4p
crw-rw----+ 1 root root 116, 12 Feb 14 23:01 pcmC1D0c
crw-rw----+ 1 root root 116, 11 Feb 14 23:01 pcmC1D0p
crw-rw----+ 1 root root 116,  3 Feb 14 23:01 seq
crw-rw----+ 1 root root 116,  2 Feb 14 23:01 timer

Modifying /etc/security/console.perms.d/50-default-perms fixes the issue for me.
I think this bug should be reopened.
Comment 41 Rubin Simons 2008-03-18 07:11:11 EDT
I agree, I have the same issue as parent: ConsoleKit running in levels 2345,
permissions wrong in /dev/snd/* and /dev/dsp*. This IS still a bug.
Comment 42 Mathieu Baudier 2008-05-10 09:04:24 EDT
Hi,

I confirm that I have the same pb and that the authorizations are not updated by
ConsoleKit.
(tech infos below)

Finally I put the following (ugly) hack in my /etc/rc.d/rc.local (called at
startup) and it works (that is, all users have sound access):

/etc/rc.d/rc.local:
# Force access to the sound device
# see https://bugzilla.redhat.com/show_bug.cgi?id=292201
chmod -R a+rw /dev/dsp
chmod -R a+rw /dev/snd/*

Hope it helps until we could have a cleaner solution...

Mathieu

## TECHNICAL INFOS
[root@thedoors ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel
82801DB-ICH4 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

[root@thedoors ~]# uname -a
Linux thedoors.vienna.argeo 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007
i686 i686 i386 GNU/Linux

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