Fix for USE_POSIX_THREADS in auth-pam.c

Sean O'Malley picasso at
Thu Oct 30 17:09:28 EST 2003

On Thu, 30 Oct 2003, Damien Miller wrote:

> Steven Michaud wrote:
> > For example, Christian Pfaffel posted a patch to this list on 9-17
> > with hacks to force Kerberos credentials to disk and to use
> > ssh_msg_send() to send the PAM environment from the child process to
> > the parent.  (His patch was in an attachment and got dropped.  But
> > fortunately he re-posted his message to the MIT Kerberos newsgroup a
> > few days later, and this time the attachment came through --
> >
> Please try the one at
> It has been sitting there with little feedback for a while.

I tried this a while ago and it still didn't work.

> > In fact this solution works just fine (as long as your OS has support
> > for POSIX threads).  But a small change was required to the "thread"
> > code in auth-pam.c:  The man pages for Linux PAM (also used on
> > Darwin/OS X) and Solaris PAM say that PAM isn't thread safe unless
> > each thread uses a different PAM handle.  But that's useless for us --
> > we need both threads to share a single PAM handle.  Instead we should
> > use a mutex to prevent the single handle from being used by more than
> > a single thread at a time.
> We won't be supporting threads, they add way more complexity then they
> solve. The code is still ethere because some people may want to use it,
> at their own risk.

It doesn't sound like this patch is supporting threads in PAM persay. I
mean literally from the sounds of the patch. It is not threaded. Thus
doesn't break..

> I'd prefer to explicitly export state from the PAM child back to the
> parent (hidden state is a bad idea, especially in a security API).
> Getting the above patch reviewed would be a start in this direction.

Is this even going to work things like AFS and Kerberos? I am not seeing
how this is going to work at all since copying the state goes against what
AFS does with pags (I assume kerberos works extremely similarly).  Kudos
to you if you do, but in the meantime we need something that works. We can
ill afford to have release versions of OpenSSH just not work especially
when the newer versions cover vulnerabilities.

I really am also not seeing the vulnerability as to why you _need_ to copy
the child to the parent. I mean literally if a pam module is allowing
certain illegal behavior. It isn't the fault of SSH. If someone gains root
access to change the pam modules you are fried anyway. What am I missing
besides an out of the box release of OpenSSH that actually works with PAM
the way it is supposed to?

More information about the openssh-unix-dev mailing list