Russ Allbery wrote:
Douglas E Engert <[EMAIL PROTECTED]> writes:
Password? I thought we are talking K5, where the K5 ticket is obtained
either via pam_krb5, or via delegated GSSAPI credential as sshd does, so
AFS only needs the location of the ticket cache.
The thread started with a discussion of the pam_afs module in the current
source tree, which uses the kaserver.
If I was to integrate pam_afs2 into the AFS source tree would it be
considered for inclusion?
I looked at it extensively during the Hackathon and I don't think it's the
fully correct approach. It's a step in the right direction, but I have a
similar start already that doesn't use a separate source of the AFS system
call layer.
If it was integrated into the source, I would expect to use the
lsetpag, and glue source and header files to be able to get a PAG. These
two source files don't require the rest of AFS. Thus the pam_afs2 does not
depend on any additional AFS or Kerberos libs.
I should have a similar module for testing before too long (a
few months at most). See the design specification that I sent to
openafs-devel a few weeks back; basically, the goal is to standardize on
the kafs interface and write a PAM module that uses it with some fallbacks
as needed and support for an external aklog program if one must.
I would rather avoid the kafs interface and use the external aklog
if at all possible. It avoids bringing in any additional AFS libs
and their dependencies into an application that calls PAM
thus avoiding clashes and keeping it simple.
It's better than anything else we have right now, though, so I'm happy to
recommend it to people in the interim.
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
