> -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Mkrtchyan, Tigran > Sent: Wednesday, May 22, 2013 5:58 AM > To: linux-nfs@xxxxxxxxxxxxxxx > Subject: expected unxpected behavior > > > > Hi, > > we hit some strange behavior which is expected from one side, but > unexpected at the same time. > We run our nfs server with v3 and v4. Due to misconfiguration in idmapping, > we got some files to be owned by uid -1. Which is ok, as with v4 server > returns nobody. Nevertheless, this prevent to list the directory with v3. This > is the result of uid_valid()/gid_valid() calls in nfs3xdr.c:decode_fattr3. The > uid_valid/gid_valid checks that provided uid/gid are not -1. > Probably this is ok. My confusion is: a) one file with bad uid/gid prevents > listing of a directory, b) in nfs v3 spec uid3 (as well as uid_t in linux) is > unsigned int 32 and value 0xffffffff is absolutely valid. > So, theory has it that uid/gid == -1 is invalid in POSIX. If you look at functions like chown(), setreuid(), etc, then the value '-1' is used to indicate absence of an argument. That said, I agree with you that this kind of client-side validation of the uid/gid values is bogus, and we should certainly not be doing it in the XDR code. I'll see what we can do about a fix. Cheers Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
