I am searching, why I can`t use gmplayer volume control with alsa under KDE as "user". Gentoo 2004.1 with the latest official changes. On my system were two users, "root" and "user". "User" is member of user, wheel, audio, video, cdrw, users groups. There is alsa used as system core sound component. Due to aplication (stupidity) compatibility, OSS emulation is used too. When I launch gmplayer as "user" and try to change volume, nothing is happen. Gmplayer reports problems with attach to mixer etc. to console. "Root" can change volume without problems. After long (and wrong way) searching for problems with alsa and mplayer I found, that there are some strange changes to owner and permission at /dev/snd*, /dev/sound/* and /dev/video/* device files. If root is loged in directly from console, /dev/sound/*, /dev/snd/* and /dev/video/* files has this permissions and owners : root:audio 660 That`s expected and OK. When logs in "user", "root" see that permissions were changed to user:audio 600 When user loged out, permissions were changed to root:audio 600 (not 660) I tried to disable devfsd /lib/dev-state functions and tried it again. Nothing is changed. I found, that devfsd.conf has inconsistent permissions set with /etc/security/console.permissions. Devfsd.conf propagates (the good one) root:audio 660, but console.permissions expects root:audio 600. When I changed console.permissions to 660 from 600 I got the same functionality, but when "user" loged out, permissions changed to 660 not to 600, so it is little better. Next I found, thet newly created "user1", when loged in with the "user" loged in, don`t change owner to "user1" to /dev/sound,snd,video device files. Owner was not changed. If is at the first loged in "user1", it takes ownership of /dev/sound,snd,video files and next loged in "user" don`t change it. So for me, I`ll use next login scheme. First, after boot, logs in "user" and he owns /dev/snd,sound,video files with 660 permissions and next logs in with "user1" which will not change owner of /dev/snd,sound,video files and use it throught write permissions to audio group to get volume control properly working. It seems for me, that PAM is doing that, but I can be totally wrong. Reproducible: Always Steps to Reproduce: 1. Alsa, alsa-oss emulation. Log in as root from console and list permissons of /dev/sound/*, /dev/snd/* and /dev/video/* device files. 2. Log in as any user and see changes to permissions of /dev/sound/*, /dev/snd/* and /dev/video/* device files. 3. Log in as another user and see that permissions of /dev/sound/*, /dev/snd/* and /dev/video/* device files is not changing. Actual Results: Unexpected and unneeded changes to /dev/sound/*, /dev/snd/* and /dev/video/* device files permissions and ownership. Expected Results: Permissions fixed to 660, owners are root:audio without changes.
This isn't a kernel issue.
Anyway, what program is causing the permissions to change? it looks like this is a pam issue, not a udev, or kernel issue... who's the pam maintainer these days?
I had the same problem and fixed it by editing /etc/security/console.perms and commenting out nearly all lines. This prevents pam_console.so from chowning anything except /dev/vc[1-6].
dup from #66268 ?
Fixed in pam-0.78.
