Bug 2114 - pam_console doesn't work
Summary: pam_console doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-10 14:19 UTC by Theodore Tso
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-04-12 16:13:16 UTC

Attachments (Terms of Use)

Description Theodore Tso 1999-04-10 14:19:17 UTC
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,

Comment 1 Michael K. Johnson 1999-04-11 21:18:59 UTC
I cannot reproduce either of these.  Can you please post here
the output of
  rpm -q pam
  ls -lR /var/lock/console*
for my perusal?

Comment 2 Michael K. Johnson 1999-04-11 21:38:59 UTC
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@MIT.EDU> 04/11/99 23:39 -------

Comment 3 Michael K. Johnson 1999-04-12 14:56:59 UTC
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.

Comment 4 Michael K. Johnson 1999-04-12 16:13:59 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.