The auth function to pam_console, which apparently is supposed to return true if the current user has exclusive access to the console, doesn't work. This can be demonstrated by logging into a text console and after applying the workaroound I describeed in bug #2110 so that X wrawpper will acatually *find* the X pam configureation file, trying to run startx. It will fail. Likewise, attempts to run the command "halt" will demand a password and then fail, because pam_console is failing. If you place pam_console as a required auth facility in su's pam configuration, it will also fail. Once you remove pam_config.so, it works again. Finally, halt is echoing the password it demands. Bad, bad, bad!!
I cannot reproduce either of these. Can you please post here the output of rpm -q pam and ls -lR /var/lock/console* for my perusal?
More information: the auth component returns PAM_SUCCESS if you are on the console at all (that is, if the file /var/lock/console.lock/<username> exists; this file is created by the session part of pam_console if you are logging on at a recognized console) regardless of whether you have the exclusive console lock (/var/lock/console contains <username> and the managed console devices are owned by <username>). I suggest that to help track down what is happening on your system, you look in /var/log/messages and /var/log/secure to see if pam_console is telling you what is wrong. If it isn't, please add the debug argument to the pam_console.so module and try again. If that doesn't make the problem obvious, please rm -f /var/lock/console /var/lock/console/* and then try logging in on a text console to see if the problem still happens. For halt to be echoing the password you type, misc_conv() in libpam_misc would have to be completely broken. That's stable code that I don't expect to be randomly broken, as it is used successfully all over the place. This is another thing that I cannot reproduce locally. ------- Email Received From "Theodore Y. Ts'o" <tytso> 04/11/99 23:39 -------
If console_helper can contact a valid display, it does so. I'll bet you dollars to donuts that a password box is showing up on :0 Perhaps I should explicitly disable that if $DISPLAY is not set and stdin is a tty, and in that case not even have gtk_init_check() try to contact a display. As far as pam_console goes, the idea is that console equivalence is a fundamentally dangerous (though powerful and useful and important to ease-of-use) thing and that we need to give sysadmins a way to easily disable all console equivalence as well as an easy way to disable it on a per-app basis, and removing a file or set of files seemed the simplest way to do it.
In looking into smarter display handling in consolehelper, I found one bug that I am dead sure caused it to hang for you. It is fixed in usermode-1.9 Because I think that everything you have mentioned so far has been addressed between the -41 release of XFree86, usermode-1.9, and the next pam release we cut (0.66-12 -- still working on some unrelated stuff in pam), I've marked this as fixed. If you can reproduce this later with all those packages updated, please reopen the bug. Thanks for your help!