Also, the recovery issue can come up with the server's cache of RPCSEC_GSS contexts is under pressure. I really think we want an RPCSEC_GSS-level solution for this. I don't think we can address this problem entirely in the GSS stack. Since RPCSEC_GSSv3 isn't done yet, maybe now is the time to work on a solution there. I'd build the solution by borrowing tech from Kerberos. The server would mint a ticket for itself using some local secret key for the ticket's encrypted part and with authorization data storing all of the relevant server-side authorization context for the client principal, then the server sends a KRB-CRED with that ticket and session key with the KRB-CRED wrapped in a GSS wrap token OR with an encryption key for the KRB-CRED based on GSS_Pseudo_random() OR it sends the ticket and the client uses GSS_Pseudo_random() to compute the same session key that the server did. Nico -- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
