On Fri, Nov 4, 2011 at 11:30 AM, Adamson, Andy <William.Adamson@xxxxxxxxxx> wrote: > Well, don't all GSS mechanisms have credentials? We use the UID to map between the RPCSEC_GSS context and the credential, so we don't need to store the credential along side of the context. The problem is that for some mechs credentials can get huge over time (e.g., Kerberos ccaches). Ensuring that all those credentials are available when we need them in order to reestablish RPCSEC_GSS contexts with the server so we can WRITE out cached dirty blocks in a memory pressure situation is... difficult or impossible -- anything we do to make that possible will be generally brittle. If the GSS-API gave us a way to extract a "sub-credential" we might make do, BUT, that's ugly, IMO, and we still have to deal with the fact that that sub-credential's expiration time might not be convenient, thus needing extra code to refresh it proactively, and so on. I.e., a GSS-based solution to this problem could be a nightmare. An RPCSEC_GSS-based solution seems trivial by comparison. > That said, I agree that a light-weight method of re-establishing a context is very appealing. Not least because any re--auth credential refresh operations will involve only that client and server. 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
