[Bug 688] PAM modules relying on module-private data (pam_dhkeys, pam_krb5, AFS) fail

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=688

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |822
              nThis|                            |
             Status|NEW                         |ASSIGNED
            Summary|keylogin not successful     |PAM modules relying on
                   |                            |module-private data
                   |                            |(pam_dhkeys, pam_krb5, AFS)
                   |                            |fail
            Version|3.7.1p1                     |-current



------- Additional Comments From dtucker at zip.com.au  2004-03-30 12:42 -------
Here's my understanding of what's going on.  Currently this is only known to
affect Solaris, but it's possible the problem exists on other PAM-using systems.

During pam_authenticate, the modules in question (pam_dhkeys, pam_krb5) stash
some private data using the pam_set_data() calls.  In the normal case, this data
is present in a separate process (the "authentication thread") and is lost when
that process exits after completing the authentication.

Later, when pam_setcred is called to establish the process credentials (eg a PAG
for AFS or the stored DH keys, however they are stored), that private data is
not available to module, so the credentials are not established.

The data stored by pam_set_data is completely inacessible to the application (ie
sshd).  If is was stored via pam_set_item, pam_putenv or the normal environment
space, it can be copied to the main sshd process (and in 3.8 and up, it is).

Currently, the only known workaround is to enable the use of POSIX threads, as
Paul discovered.  This is because the module-private data is stored in the same
address space as the main sshd, and thus survives the termination of the
"authentication thread".  It is then copied to the child forked to run the
user's shell an is available to the pam_setcred() calls in session.c.

Note that enabling threads opens up sshd to any number of races with any PAM
module, so is not recommended unless absolutely necessary and you better hope
your PAM modules are thread-safe.  Thread support in sshd is currently a
necessary evil for these cases.  Once there is a better solution, thread support
becomes an *unnecessary* evil, and will be removed.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.