Bug 717

Summary:

AFS tokens are not generated upon login

Product:

Portable OpenSSH

Reporter:

Ian Kaufman <IDKaufman>

Component:

PAM support

Assignee:

OpenSSH Bugzilla mailing list <openssh-bugs>

Status:

CLOSED DUPLICATE

Severity:

normal

Priority:

Version:

-current

Hardware:

UltraSPARC

OS:

Solaris

Attachments:

Description	Flags
Try to export environment from PAM authentication subprocess	none
output of sshd -d -d -d	none

Description Ian Kaufman 2003-09-26 02:58:49 AEST

OpenSSH versions 3.7p1 through 3.7.1p2 on Solaris 2.6 and Solaris 8.
Solaris 8 Kernel patched to 108528-19 (cannot patch higher due to AFS issue)
Solaris 2.6 Kernel patched to 105181-35

Prior to upgrading from OpenSSH 3.6, if OpenSSH was compiled with 
the following flags:

./configure --with-pam --with-xauth=/usr/openwin/bin/xauth --with-tcp-wrappers
--with-ssl-directory=/usr/local/ssl

users could log into their machines via OpenSSH, and through PAM, an AFS
token would be generated. After upgrading OpenSSH, tokens are no longer
generated, and users must run klog to authenticate to AFS.

Please contact me if you need more information. This issue has been 
discussed at OpenAFS as well:

https://lists.openafs.org/pipermail/openafs-info/2003-September/010738.html

Thanks for your time and consideration,

Ian

Comment 1 Damien Miller 2003-09-27 09:42:48 AEST

Does this token get passed by way of an environment variable? Right now, the new
PAM code doesn't export environment variables set by the authentication subprocess.

Comment 2 Damien Miller 2003-09-27 11:19:56 AEST

Created attachment 472 [details]
Try to export environment from PAM authentication subprocess

This (quick, untested) patch tries to export the PAM environment from the
authentication child to the master process. I have no idea whether or not it
works, as I have no PAM modules that set environment variables during the auth
phase. 

Also, I was unsure whether all PAM modules pass their environment using PAM's
internal envrionment API or using the standard unix **environ. To be paranoid I
pass both :)

Comment 3 Ian Kaufman 2003-10-01 06:28:47 AEST

Damien,

Your patch did not seem to work. We believe that it is not an environment
issue, but something in the way the password is passed around in the PAM
modules. By changing the local password so that it differs from the AFS
password, normal behavior would indicate that if the AFS password is
entered, PAM would react appropriately, and AFS would authenticate the
user correctly. Currently, the user is immediately rejected from login.

We are going to test the latest OpenAFS client to see if we can get better
behavior.

Please let me know if there are some traces you would like, or other dumps.
Truss hasn't proven too enlightening so far.

Thanks for your efforts,

Ian

Comment 4 Sean 2003-10-01 23:13:46 AEST

Created attachment 476 [details]
output of sshd -d -d -d 

The AFS token is missing. It will authenticate but it either doesn't set or it
loses the token in the process. 

This is both the client side and server side output with pam_afs, ssh 3.7.1p2
with the listed patch applied, compiled with egcs on Solaris 8 ( it also didn't
seem to work compiled with gcc 2.95.x) I haven't tried it under the 3.2.x
version of gcc or solaris CC or under Linux. I don't believe it is a compiler
issue though. 

I have a sneaky suspician the afs token is getting set to the process but it
swtiches from process (priv separation?) to which the token was attached and
appears to not be set when it was just destroyed by the process switch.

Comment 5 Ian Kaufman 2003-10-03 03:48:34 AEST

I tested with privsep off. No change. I am going to
build a 32 bit machine to see if it is a 32 vs. 64 
bit issue.

Ian

Comment 6 Darren Tucker 2004-03-30 12:44:30 AEST

The issue appears to be pam_set_data().  There is a more detailed description
and a (bad) work-around in bug #688.

*** This bug has been marked as a duplicate of 688 ***

Comment 7 Damien Miller 2004-04-14 12:24:19 AEST

Mass change of RESOLVED bugs to CLOSED