Re: OpenSSH and pam_krb5
From: Fredrik Tolf (fredrik_at_dolda2000.com)
Date: Sat, 17 Apr 2004 18:41:45 +0200 To: Darren Tucker <email@example.com>
Darren Tucker writes:
> 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.
That's how I thought it would be. That didn't work then...
> > 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.
> 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).
I've got another idea (the pills didn't work, it was too
strong...). I've recently imlemented PAM authentication into yet
another project of my own, which is also single-threaded. To make it
work there, I implemented user-space coop threads using the ucontext
family of functions. It worked perfectly, but I don't really know how
portable/desirable the ucontext calls are, though, so please have your
say about that.