Re: OpenSSH and pam_krb5
From: Darren Tucker (dtucker_at_zip.com.au)
Date: Sun, 18 Apr 2004 01:05:42 +1000 To: Fredrik Tolf <email@example.com>
Fredrik Tolf wrote:
> Darren Tucker writes:
> > Good luck, fixing this looks hard when using keyboard-interactive
> > because PAM deliberately hides the information sshd would need to
> > export. I have a couple of possibly viable ideas, I'll attach them to
> > the bug when I rewrite the details a bit.
> Precisely what I was thinking as well... I was merely hoping that
> maybe PAM specifies that the private data must be contained within a
> well-defined memory space in order to make it copyable. Unfortunately
> I seem to have lost my PAM source for the moment, so I can't verify
> that. I do have my doubts, though... :-)
I looked at this option. pam_set_data() stashes its stuff in the
pam_handle which is a "blind type". With the published API, you can't
look into it, you can't even tell how big it is. Any code that can do
these things is going to be relying on undocumented internals and will
likely be fragile and non-portable.
> If that fails, I'm kind of hoping that it might be possible to
> "switch" functionality so that the main process does the PAM
> authentication. I have my doubts about that, too, though...
That sounds like the "PAM inversion" idea we've kicked around privately.
Normally, sshd forks and the child runs the PAM functions while the
parent talks to the client (or monitor with privsep). The idea is that
the after the fork, both parent and child share all the same
descriptors, so in theory it would be possible to run the PAM functions
in the parent and have the child talk to the client temporarily. (I'm
going to take a swing at writing this after 3.8.1p1 ships, but don't let
this stop anyone else saving me the work :-)
There's a couple of wrinkles identified so far:
a) There could be a rekey during this process, in which case when the
parent returns to normal it would still have the old keys. (This could
probably be fixed by using mm_send_keystate).
b) If the PAM modules crashes it will kill your entire session. (At the
moment it logs a failure and continues). This is probably not a
c) You would need to be very careful making sure the child process
wait() handling is right for all of the cases.
Another option would be some kind of coroutine implementation but that
is likely to be hideous and possibly non-portable. (See Simon Tatham's
description at , it's an extremely clever hack but you might want to
take some anti-nausea pills before following the link).
> Yeah, I managed to find that out eventually, only on GNU/Linux it's
> -lpthread (singular). I take it this is a rather experimental feature,
> considering how concealed it is?
Call it "grudging support". It's potentially dangerous if any of your
PAM modules are not thread-safe. Unfortunately, right now it's also the
only know way of getting setups like yours to work, so it's still there.
You have to know you need it, rather than random people doing
"configure --with-pthreads" simply because they read in a magazine once
that threads are cool.
> > There's also a compile-time error in that configuration that is fixed in
> > either 3.8p1 or the soon-to-be-released 3.8.1p1.
> Really? It worked perfectly well for me. I guess it will have to do if
> I really can't find another solution. Thank you very much for helping
> me with this - my pam_krb5 module finally works, even if it's using an
> experimental feature.
It might have been introduced in 3.8p1 and (will be) fixed in 3.8.1p1.
-- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.