|
Description
|
After installing the fix for 6398796, remote logins to xdm fail. When debugging,
customer reports:
>>1.Is anything core dumping? (Turn on coreadm global dumps if needed.)
Nothing is dumping core. I turned on global and global-setid dumps and
tested to make sure they were working.
>>>> 2. Is anything logged to any of the xdm error files or the user's
>>>> $HOME/.xsession-errors ?
I called "env" from my .xsession and it prints, among other things:
DISPLAY=hostname.domain.name
Note: There is no colon after the domainname.
(hostname.domain.name being my workstation where I'm running the X server and
display)
On a Solaris 10 system _without_ the xdm changes you sent me, I
instead get:
DISPLAY=hostname.domain.name:1
Running with -debug 16, you can see the display name starts out with the display
number and then loses it before setting the DISPLAY (alf is the name of the host
I'm remote displaying to in these tests):
greet alf:0
SecureDisplay alf:0
Before XGrabServer alf:0
XGrabKeyboard succeeded alf:0
pseudoReset screen 0
before XSync
pseudoReset done
done secure alf:0
SetPrompt(1, <NULL>, LOGIN_PROMPT_NOT_SHOWN(0))
pam_msg: PAM_PROMPT_ECHO_ON (2): 'login: '
SetPrompt(0, login: , LOGIN_PROMPT_ECHO_ON(1))
dispatching alf
[...]
Verify test ...
verify succeeded
user environment:
DISPLAY=alf
So the :0 is being stripped after printing "done secure" but before the "dispatching"
printout. Tracing through the code finds a small but significant typo in the PAM
initialization for remote hosts - it strips the display specifier off the end of the
display in order to past the hostname to PAM as the PAM_RHOST:
if (d->name[0] != ':') { /* Displaying to remote host */
char *hostname = strdup(d->name);
if (hostname == NULL) {
LogOutOfMem("GreetUser");
} else {
char *colon = strrchr(d->name, ':');
if (colon != NULL)
*colon = '\0';
RUN_AND_CHECK_PAM_ERROR(pam_set_item,
(*pamhp, PAM_RHOST, hostname));
free(hostname);
}
}
Unfortunately, the colon is being set to nil in the wrong copy of the string - in the
one we keep for the display name, not the temporary copy we made for PAM. Changing
the strrchr call to strrchr(hostname, ':') corrects this error and allows remote login
to proceed correctly.
[This bug affects Solaris Nevada only - the problem was found before 6398786 was
backported to Solaris 10, so was fixed in the initial integration of the 6398786
code to Solaris 10.]
|