Date: Sun, 28 Feb 1999 03:17:20 +1100 From: Bruce Evans <bde@zeta.org.au> To: asmodai@wxs.nl, dfr@nlsystems.com Cc: current@FreeBSD.ORG, mi@kot.ne.mediaone.net, sthaug@nethelp.no Subject: Re: Really! strange uid value Message-ID: <199902271617.DAA18010@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ >> >> = >> >> =funny, the same value. There is something left out very fundamentally >> >> =somewhere. >> >> >> >> Just FYI. This number is 0xFFFFFFFE in hex... A search for this number >> >> through the sources does not bring anything under NFS itself, though the >> >> following may give a clue: >> > >> > Remember that the "nobody" user is uid 65534 (0xfffe). The signed >> > extension of this to 32 bits is 0xfffffffe. Maybe you're seeing uid 0 >> > being translated to 65534 (due to NFS) and then sign extended. >> >> Could be, but that is still not correct behaviour as far as my knowledge >> goes. It should not get sign extended IMHO. Am I correct in assuming this >> (call to the more knowledgeable ones)? > >Do you have a simple repeatable test? What OS is the server running? FreeBSD server, FreeBSD client, nfsv3: # cd world_writable_nfs_mounted_directory_which_shouldnt_exist # cat ^\ # ls -l cat.core -rw------- 1 4294967294 wheel 225280 Feb 28 03:06 cat.core 4294967294 is just the default mapped uid for root. It is (uid_t)-2. See mountd sources. It has nothing to do with user nobody or 65534, except possibly on buggy clients that silently truncate it mod 65536. Perhaps it is a bug to use (uid_t)-2 instead of 65534. For clients with only 16-bit uid_t's you would want to keep all uids on the server < 65536. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902271617.DAA18010>