Aha. Can you please run system-config-soundcard, create /root/scsconfig.log and
attach it here?

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?

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.  

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.

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.)

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. 

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.

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.

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.

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)

Changing the component to hal as this seems more appropriate.

Versions here on both machines are:

hal-0.5.10-1.fc8
hal-info-20071030-1.fc8

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.

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.)

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.

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.  

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!

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]# 

(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.

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?

Joachim, can you check the contents of /var/lib/hal/acl-list on your machine please?

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.

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.

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.)

(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.

(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?

(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.

(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 ;-).

(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.

@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. 

Created attachment 260581 [details]
My /var/lib/hal/acl-list

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).

(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.

(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.

(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.

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!

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.

(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!

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.

(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.

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.

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