This bug may carry over into Red Hat 7.0, I don't know.

Quick summary: If you telnet to a Red Hat 6.2 box that is NOT running
X-Windows, and then use the "su" command (to become root, or anyone for
that matter), there will be a several-second long delay (maybe 30
seconds...not sure) after entering the password.  There will be another
long delay after typing "exit" to get back to the original user shell.


Detailed info: When you first login (via telnet), this error message
appears on /var/log/messages:

Nov 14 14:20:51 archer pam_console[11662]: can't find device or X11 socket
to examine for 4

Now, when I try to "su", there is a very long delay of several seconds. 
There is another long delay when I log out.

I did

strace su eic   (where eic is a username on my computer)

And here is where it froze up:

[...some stuff...]
[ Up to this point, there is NO "open" call which returns the integer 4.  I
think these calls are being made by PAM...]
open("/etc/passwd", O_RDONLY)           = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=1796, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0$read(3, "root:ioog0Wb1DBAq6:0:0:root:/roo"..., 4096) = 1796
close(3)                                = 0
munmap(0x40019000, 4096)                = 0
pipe([3, 4])                            = 0
fork()                                  = 11595
close(4)                                = 0
read(3,

Here this is a very long read delay.  FIXME!    

"", 256)                        = 0
--- SIGCHLD (Child exited) ---
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 1], 0, NULL) = 11595
close(3)                                = 0
close(4)                                = -1 EBADF (Bad file descriptor)
[...more...]

	Notice the EBADF on the close(4).  I think that "4" is the same "4" from
the /var/log/messages entry that pam_console reports.

	Here is /etc/pam.d/su, it is whatever the default config is:

#%PAM-1.0
auth       required	/lib/security/pam_pwdb.so shadow nullok
account    required	/lib/security/pam_pwdb.so
password   required	/lib/security/pam_cracklib.so
password   required	/lib/security/pam_pwdb.so shadow use_authtok nullok
session    required	/lib/security/pam_pwdb.so
session    optional	/lib/security/pam_xauth.so

	Notice that the delay (i.e., blocked read :) goes away if I change the
/etc/pam.d/su entry to read like this:

#%PAM-1.0
auth       required	/lib/security/pam_pwdb.so shadow nullok
account    required	/lib/security/pam_pwdb.so
password   required	/lib/security/pam_cracklib.so
password   required	/lib/security/pam_pwdb.so shadow use_authtok nullok
session    required	/lib/security/pam_pwdb.so
#session    optional	/lib/security/pam_xauth.so

	...i.e., comment out pam_xauth.so.

	Is this problem caused by the fact that X is not running?  I think so.  If
it is, bitch-slap whoever wrote pam_xauth.so for thinking that everybody
runs X.


Cheers, 
Derek Simkowiak
dsimkowiak@excite.com

P.S.> Google could not find any information about this problem, except for
a couple of email archives reporting the error message in
/var/log/messages.