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

[Russ Allbery]

Jeffrey Altman <jaltman@columbia.edu> writes:

> It sounds like you are describing ktc_SetToken().  This function takes a
> ktc_principal representing the client, a ktc_principal representing the
> server, and a ktc_token.  There is nothing Kerberos about any of these
> structures.  This is an already existing standard function provided by
> OpenAFS.

Okay, good, that's what I thought.

What I'd like to see is, basically, for that function to be put into a
separate library independent of all of the other OpenAFS libraries, since
right now it's difficult to link against OpenAFS libraries in PAM code for
a variety of reasons.  (Sorry, I'm probably repeating myself, but I'm not
sure that I've managed to be clear.)

> The ktc_xxx functions don't drag in Kerberos.  What does drag in
> Kerberos is the function used to obtain the afs service ticket that is
> in turn used to construct the ktc_token.  If you are authenticating with
> Kerberos you will need the Kerberos libraries to obtain the service
> ticket for you or at the very least provide the interface to the
> credential cache to read it.

Right.

> What are you suggesting be used to provide the separation between the
> layer that obtains the Kerberos ticket and the call to ktc_SetToken()?

Right now, the aklog implementations.  Those aklog implementations can
then be linked against whatever Kerberos libraries one chooses and against
the AFS system call library and won't have to worry about any conflicts
between the two or problems with OpenAFS library linkage.

Eventually, if we end up stabilizing around one particular blessed
authentication method for AFS, maybe OpenAFS can also provide that
linkage.  Or maybe some Kerberos v5 PAM implementation will want to go
ahead and provide AFS tokens as an option and will include the linkage.
Basically, anything that wants to will do the linking; the idea of
providing ktc_SetToken() in a separate library with setpag() is so that
whatever chooses to do the linkage doesn't have to worry about library
conflicts in the process of getting at that call.

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