Re: permissions on sound devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wednesday, Dec 17, 2003, at 13:31 America/New_York, jurvis lasalle wrote:
On Tuesday, Dec 16, 2003, at 23:49 America/New_York, Pete Nesbitt wrote:
On December 11, 2003 03:24 pm, jurvis lasalle wrote:
I have a problem that systematically occurs, but I cannot reliably
reproduce. Upon console login, ownership of sound devices is given to
the user. Upon logout, it reverts to root. Sometimes however, the
former user retains ownership and the next user cannot direct output to
the sound devices. I can't recreate what causes the break down but
across the lab can see that it generally happens after 2 weeks of
uptime. My research turns up the solution of chmod 660 the sound
devices and chgrp them to audio after adding all my users to that
group. OK- that will work and not necessarily be too large a pain in
my ass, but that doesn't satisfy my desire to know what's breaking
down. Does anyone here have suggestions for diagnosing this problem?
Jurvis LaSalle

Hi Jurvis,
The initial user to log onto the console is given hightened privilages
regarding accessing devices and halting or rebooting the system.
To see what is effected, the users privs, and the user/privs afterwards, have
a look at the file:
/etc/security/console.perms
--
Pete Nesbitt, rhce


Thanks, this is a start in finding the breakdown. I can see that console users should get ownership and 0600 perms for <sound>, and that it should revert to 0600 root.root upon logout. Can anyone recommend any diagnostic commands I can run when this process appears to breaks down?
Ahhh... answer me this: somehow the perms don't revert back to 0600 root.root at logout- will the next console user still be made owner of <sound>? If yes, does that mean PAM is dropping the ball at login time? Does that point the finger at pam_console_apply? This is deeper into Linux than I've previously delved- any pointers or assistance is appreciated.
Jurvis LaSalle


Further investigation shows that pam_console_apply is just doing what it should. The problem is that /var/run/console.lock contains a username that isn't currently logged in at the console. How could such a situation arise? Looking across the lab, I see that nearly half of the computers have a mismatch between the console user (or lack thereof) and /var/run/console.lock. What's going on here and what can I do about it?
TIA,
Jurvis LaSalle



-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux