On Fri, Oct 01, 2021 at 09:49:50AM +0300, Volodymyr Khomenko wrote: > > So, I can verify that --security=krb5 works after this patch but not > > before, good. But why is that? As you say, the server is supposed to > > ignore the sequence number on context creation requests. And 0 is valid > > sequence number as far as I know. > > By design of RPCGSS we have a 'last seen seq_number' counter on the > server side per each GSS context > and we must not accept any packet that was already seen before (we > also have a bitmask of several last requests for this). > This 'last seen counter' is unsigned int32 (the same as seq_num) so we > can't just init it to -1 so next seq_num=0 will be valid. > The most obvious implementation is to init it last_seen_seq_num to 0 > so the very 1st packet after NFS4 NULL must be 1 to differ from last > seen seq_number. Note in theory gssapi mechanisms can require multiple round trips (in the GSS_PROC_CONTINUE_INIT case), so this wouldn't actually avoid duplicate sequence numbers. In any case, the rfc is unambiguous here: "In a creation request, the seq_num and service fields are undefined and both must be ignored by the server." > A better implementation (theoretically) can set this counter to > 'undefined' state by additional flag, but this is more > resource-consuming > (you need to process is_inited flag + last_seen_seq_num instead of > just one counter). > If the last seen seq_number is undefined during GSS initialization, > then strictly speaking we can send ANY seq_num for the very 1st > request after NFS4 NULL. Right, again, from RFC 2203, " The seq_num field can start at any value below MAXSEQ." It can be implemented without the need for an is_inited flag. The initial sequence number of 0 really did find an actual bug in the server, so pynfs is definitely doing its job in this case! --b.
