Russ Allbery wrote: > I think you're missing my point. > > The "make this a token" function doesn't link against any Kerberos > libraries. It only has a little more complexity than the setpag > function. All it does is take the blob of token that one has come up with > via magical means and push it into the kernel. It is the syscall > interface; nothing more or less.
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. > As such, it clearly doesn't drag in threads, OpenSSL, multiple versions of > Kerberos, or anything else, and it won't cause problems for vendors and > won't cause conflicts with native libraries. It's just the bit that > OpenAFS has to provide to let you talk to the kernel layer. 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. What are you suggesting be used to provide the separation between the layer that obtains the Kerberos ticket and the call to ktc_SetToken()? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
