Jeffrey Altman <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
