Re: Problems with kerberos auth - possibly against ADS - since nfs-utils-1.2.3

[NeilBrown <neilb@suse.de>]

On Thu, 18 Aug 2011 12:43:07 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> 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...)

It stopped happening?  You mean it is already fix?  Have I been look at old
code AGAIN ??

Though I was looking at most recent libtirpc and gssglue and I think I was
running both of these...  Maybe I had a slightly old krb5-mit library?

confused...

NeilBrown

> 
> --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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html