Fix for USE_POSIX_THREADS in auth-pam.c

[Steven Michaud]

> 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..

You've completely missed the boat :-)

But I'm not sure why (you don't know threads?, you haven't read the
patch carefully?, you tried it and it "didn't work"?), so I don't know
what to say next.

Let's assume that my patch "didn't work":  One thing to remember is
that you need to define USE_POSIX_THREADS, and that you may also need
to add libpthread.so to the list of libraries that sshd links to.

The way I did this was to add the following to my "configure"
parameters:

"CPPFLAGS=-DUSE_POSIX_THREADS LDFLAGS=-lpthread"

Sean O'Malley wrote:

> 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 --
> > > http://diswww.mit.edu:8008/menelaus.mit.edu/kerberos/19973.)
> >
> > Please try the one at http://bugzilla.mindrot.org/show_bug.cgi?id=717
> >
> > 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?
>