On December 17, 2003 01:14 pm, jurvis lasalle wrote: > 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 I expect the lock file is in place so that cosole privs are not reassigned until after the next reboot. As I understand it, the whole idea is that the first console user is given hightened access, not any console user, so the lock makes sence as it indicated the privs have been assigned and should not be repeated. -- Pete Nesbitt, rhce -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
