Description of problem: After having logged out as xguest, a user who tries to log back in immediately is prompted for a password. After about 30 seconds, logging in without a password works again. Version-Release number of selected component (if applicable): xguest-1.0.7-7.fc12 How reproducible: Happens every time Steps to Reproduce: 1. Log in as Guest user. 2. Log out Guest user. 3. Try to log back in immediately. Actual results: The user is prompted for a password. Expected results: The user should be able to log in without a password without having to wait. Additional info: After logging out, I see the following two processes owned by xguest: /usr/bin/pulseaudio --start --log-target=syslog /usr/libexec/pulse/gconf-helper After about 30 seconds, these processes stop running and the Guest user can log in without a password. After removing PulseAudio as per the instructions at the following URL, this problem seems to go away. http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workarounds
Ray have you fixed the problem where gdm kills the pam stack?
Uh? what's the problem here?
The problem is that the xguest user can't log in if there are still processes from the last session. This is apparently due to the authentication procedure which involves SELinux. On my computer, two processes don't terminate after the user logs out until about 30 seconds later. Once those processes do terminate, then the user can log in as xguest (without a password).
The problem is it takes 30 seconds for the pulseaudio processes to exit after logout. Secondarily the pam module that xguest uses attempts to kill the processes that are left around at logout, but xdm is killing it before it can kill the procesesses. xguest is not allowed to login without a password if any processes are still running. The reason for this is a hacker could login to a kiosk machine and start a processes to wait for the next user of the kiosk to login. Then he can grab info like passwords.
Hmm, sho shouldn't this bug then be assigned to that PAM module, not PA? WHat's the name of that module?
This does not sound like a pam problem. This sounds like either the session is not being closed correctly or the above programs cannot receive the sigterm signal. Are they on the real-time scheduler? Do they expect realtime signals? Do they obey sigterm?
This is a pulseaudio bug since there are pulseaudio processes that continue to run for approximately 30 seconds after a user logs out. Secondarily there is a gdm bug that kills its subproceses gdm-passwd before it completes. There is no bug in pam_selinux_permit.so which makes sure no processes with the login UID are running before allowing a new user to login. It does attempt to send the kill signal to all processes for that UID when the user logs out, but gdm kills it, before it kills the bad processes. (Think of the end scene in the movie Omen). http://en.wikipedia.org/wiki/The_Omen "Just as Robert is about to stab Damien, the police arrive and order him to stop. When Robert does not comply and tries to stab Damien, he is shot dead by the police."
it's exactly like that. GDM isn't fixed yet. Of course, your killing code, and gdm's killing code wouldn't matter at all if the pulseaudio bug is fixed.
I don't see why this is a "bug" in PA. PA stays around until 30s after it was last used. Which is a very reasonable scheme in my eyes. "last used" means that either at least one client is connected to it, or the XSM session it was started from is still around, or CK tells us the user owning it is still logged in at least once. If neither of this case we keep around for a while and if things don't change in that time, we terminate ourselves. This behaviour makes sure that we can share and reuse a single PA instance among multiple sessions of the user (be them X, console, ssh), and even among processes that are executed outside of a session (e.g. cronjob), and we do so without having to do full start/stop cycles for PA for even the tiniest of operations, but on the other hand still make sure that PA goes away if it is not used. I do believe that this scheme makes a lot of sense and for normal users is sane and useful behaviour. However, the selinux guest user is not a "normal" user, it has different semantics. But I see no reason to add a special hack to PA so that if it sees that if `whoami` == "guest" it terminates itself right-away instead of lingering around. So really, I don't consider this a "bug" in PA, and I certainly don't want to change the current behaviour. If the selinux/gdm guest user needs special semantics for the guest user, then it should enforce it and not expect that PA detects this and does something completely different than it would normally do. Anyone would be upset if I'd close this now as NOTABUG?
Which is a very reasonable scheme in my eyes. "last used" means that either at least one client is connected to it, > NO client is connected to it. or the XSM session it was started from is still around, > Not sure what this is, but all procesess started by xguest are gone. or CK tells us the user owning it is still logged in at least once. > xguest is totally gone, so either consolekit is lieing or this code does not work. When xguest logs out, all xguest processes are shutdown. There should be no xguest UID processes running on the system. Multiple xguest users are not allowed to be logged in at the same time. So something in the cleanup is not working correctly.
Another option that you probably would not like is a way to tell pulseaudio UIDs to exit on immediately.
pulseaudio -k will cause pulseaudio to exit immediately.
Well I could do this except you kill me before I can...
fixing that is the 4th item down on my whiteboard
(In reply to comment #10) > Which is a very reasonable scheme in my eyes. "last used" means that > either at least one client is connected to it, > > NO client is connected to it. > > or the XSM session it was started from is still around, > > Not sure what this is, but all procesess started by xguest are gone. XSM = x session manager. i.e. some archaic X/ICE protocol used by gnome-session among others for doing session stuff. Basically what I wanted to say is that PA considers gnome-session being around a reason to stay around too. > When xguest logs out, all xguest processes are shutdown. There should be no > xguest UID processes running on the system. Multiple xguest users are not > allowed to be logged in at the same time. So something in the cleanup is not > working correctly. Note that PA stays around for 30s even when all the three conditions i pointed out tell pa it is not used anymore. That said, if there is some code that does the equivalent "killall -u xguest" and PA nonetheless is still around, then this means the code is broken. "pulseaudio -k" will shutdown PA. However doing a pa specific hack here seems unclean to me. Anyway, as I understood the "killall -u xguest" code lives in gdm? Reassigning to gdm then.
Well it actually lives in pam_selinux_permit, but gdm is killing the process that is trying to killall.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.