NFS: rpcsec_gss with Linux clients

[Rick Macklem]

Attila Bogar wrote:
> Hi Rick,
> 
> On 02/09/12 00:57, Rick Macklem wrote:
> 
> 
> This certainly sounds bogus. I can see an argument for 2 TCP
> connections for trunking, but since a security context should only be
> destroyed when the client is done with it, doing a DESTROY doesn't
> make sense? (There is something in the RPC header called a "handle".
> It identifies the security context, and it would be nice to check the
> wireshark trace to see if it the same as the one being used on the
> other connection?) The Linux guys say this is a bug in Linux:
> http://www.spinics.net/lists/linux-nfs/msg32466.html
> 
> I'm going to open a bug with Red Hat and test the upstream linux
> kernel + nfs-utils against this bug.
> 
> As per their message it's also interesting why the rpcsec destroy mic
> evaluates to GSS_S_DEFECTIVE_TOKEN.
> This is the 2nd root of the original problem.
> 
> That would indicate the encrypted checksum isn't correct. It
> might be using an algorithm only supported by the newer RPCSEC_GSS_V3?
> If I check the trace with wireshark 1.4.6 it reports rpc malformed
> packet.
> However if I check the trace with the newest 1.8.2 it's OK (could be a
> bug in wireshark, though).
> Anyway it says rpc version 2 and gss version 1.
> 
> 
> 
> I've attached a small patch with disables setting client->cl_state to
> CLIENT_STALE for this case, which you could try, to see if it helps?
> Yep, it works perfectly. Confirmed. Please go ahead to commit and
> merge to stable.
> 
Ok, thanks for testing it. I am waiting for a review from dfr@, but will
get it committed soon.

Have a good week, rick

> Attila
> --
> Attila Bogár
> Systems Administrator
> Linguamatics - Cambridge, UK http://www.linguamatics.com/