On Thu, Aug 18, 2011 at 07:19:06PM +1000, NeilBrown wrote: > I think that does exactly describes what we were seeing. > We ended up working around it by adding > > default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 > > to the client config, and recommending a server upgrade. > > > BTW I've been trying to track down why a successful kerberos negotiation > sends a corrupted RPCSEC_GSS_DESTROY request just before closing the > connection. (No useful comment here, just: thanks! That was driving me crazy, till it just stopped happening for no apparent reason, before I got a chance to look any closer...) --b. > > There are two issues here. > 1/ Why is it trying to send a DESTROY request > 2/ Why is it corrupted. > > It is just as well that it is corrupted else the server would forget the > session that has just been negotiated. > > It is sending a DESTROY request because that is what AUTH_DESTROY called in > gssd_proc does. But it shouldn't. After a call to > authgss_get_private_data() the context is owned by someone else so > AUTH_DESTROY should free the memory, but not DESTROY anything on the server. > > I think authgss_get_private_data should clear gd->established or possibly > gd->gc.gc_ctx.length so there is no attempt to use or destroy the auth internally > any more. > > But why is it corrupted? This is because the internal_ctx_id in the gssglue > layer has been zeroed by the call to authgss_get_private_data. I couldn't > easily see in the code where this is happening, but tracing confirms that it > does. A NULL internal_ctx_id doesn't stop authgss_destroy_context from > trying to destroy the context, but it does stop it from succeeding. > > So I suspect all we need to do to address this is change > authgss_get_private_data to set gd->gc.gc_ctx.length to zero. > > Does that seem reasonable to you? > > > Thanks, > NeilBrown > > -- > 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 -- 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
