SSH and PAM concerns

[Sam Hartman <hartmans@debian.org>]

Hi.  I try not to follow OpenSSH development, but from time to time I
cannot avoid running into new developments in the OpenSSH code base.

It's my understanding that the ssh 3.7 codebase has new PAM handling.

I don't know exactly what ended up getting released, but at least one
version of the code would break a lot of PAM modules.

I'd like to draw your attention to the PAM minipolicy found in
/usr/share/doc/libpam0g.  This document does not actually have the
force of policy in that it is not in the Debian policy document, but
it certainly in a set of guidelines for interoperability.  If the
Debian ssh package ends up adopting PAM code that violates these
guidelines it will break user expectations.

I believe that it is important that the default behavior of the ssh
package:

1) call all the PAM modules in a process that will ultimately be
   inherited by the user's session.  The PAM modules need to be able
   to change the environment and other attributes of the process.  I
   realize that environment could be handled another way, but we
   cannot enumerate all the possible attributes of a process that
   people may wish to change using PAM modules and the only way we can
   guarantee that things work is for the PAM modules to be called in a
   process that ends up starting the user session.

2) The PAM callbacks need to run as root.

3) pam_close_session and pam_end need to be called in the same process
    or a process that inherits from the process where PAM callbacks
    are, using the same PAM handle.  I.E. you cannot call pam_start
    and pam_open_session in one process then pam_start and
    pam_close_session in another module.

If the new PAM code in the openssh packages violates these
constraints, we should probably discuss how we want to handle things.