PAM function ordering

Nicholas Wilson nicholas at nicholaswilson.me.uk
Sun Jan 20 20:53:35 EST 2013


Damien,

On Jan 20, 2013 2:02 AM, "Damien Miller" <djm at mindrot.org> wrote:
>
> Hmmm. We are probably not the best learning example for PAM, we're
> probably more of a cautionary example of how PAM's API doesn't fit with
> modern, privilege- minimising and separated applications.

It's certainly true that in my application, we make a few more concessions
to PAM in our architecture than OpenSSH does! It is possible to fork off a
PAM process for authentication, then session/setcred, and keep it around to
reuse for spawning commands. The main process can still use privsep to
avoid interpreting client input in the privileged process. Regardless
though of whether you're a model PAM consumer or not, you at least have
been tested with every implementation and module by someone.

> Right, anything that uses pam_get/set_data will break on OpenSSH. So
> far we've accepted this as a price of keeping our PAM code sane and
> easy to reason about. Various alternatives have been suggested, but all
> have turned my sunglasses black.

Would you use a "pam_getdatalist" function then if it were available, as a
way of transferring module context from one process to another? You could
suggest it to OpenPAM or something and pull it in with autoconf.

> > Similarly, I wonder if there are any known guidelines on how
> > pam_setcred(DESTROY) and pam_close_session are meant to be called, and
if
> > there are any constraints in the order between to be portable?
>
> No, there are no guidelines for most of PAM. That's part of the problem.
>
> Darren has a list of problems with PAM at http://www.dtucker.net/pam/

That's an extremely helpful list, thank you. I've gleaned most of that,
plus some, from research already though.

There are clear difficulties with the setcred(ESTABLISH)/open_session
order, which is why I asked specifically whether there were known issues
with setcred(DESTROY)/close_session.

Thanks for the feedback, Damien.

Nicholas


More information about the openssh-unix-dev mailing list