[OpenAFS-devel] Simplified integration of OpenAFS, Kerberos SSH and PAM (again)

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:

> For PAM I agree it should not fool with the signals. But the gafstoken
> was also written to be used from non PAM applications, such as the MIT
> rtools, and ftpd and OpenSSH. OpenSSH 3.9 and above now call the PAM
> session, so no local mods are needed any more.

Well, except that I wouldn't want to use that code in any sort of PAM
module.

> The "don't use this PAM if you don't have AFS kernel module loaded" is a
> real time problem. It might occur if a new AFS was bing installed, and
> the kernel modules did not load. If there is not some run time
> protection, PAM might fail and it could stop you from logging as root to
> fix the problem.

Well, like I said, I'm happy to leave it to someone who cares about AIX to
solve that problem, and I don't think it should be solved in the library.
The PAM module should do what it needs to do to figure out if it's safe
and then load the shared library at runtime on those systems.

Prior to AIX 5.3, PAM on AIX was an iffy proposition anyway, so before
even bothering to worry about it, I'd check to see if AIX 5.3 still has
that issue.

> Keep in mind package dependencies. We want the vendor to be able to
> easily support AFS, AFS needs to provide all the pam_afs* routines and
> related libs. I believe we need to get away from the vendor having to
> integrate krb5 with AFS for us, as some vendors will not do that.  And
> they should not have to bend over backwards as in the RedHat
> pam_krb5afs.c

> Thus no only is the lestpag needed to be separate to avoid all the
> linking problems in PAM, but OpenAFS needs to provide the pam_afs*.

Providing a PAM module that's willing to call an external program to get a
token probably isn't a bad idea, but the setpag stuff is the really
important part.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>