Date: Mon, 7 Jul 1997 11:35:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tholmes@zeus.leitch.com (Tony Holmes) Cc: FreeBSD-hackers@FreeBSD.ORG Subject: Re: uid > 32000 Message-ID: <199707071835.LAA18117@phaeton.artisoft.com> In-Reply-To: <199707071557.LAA01700@bitter.zeus.leitch.com> from "Tony Holmes" at Jul 7, 97 11:57:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been pouring through any document I can get my hands onto and > can't find if there is any significance to a user id that is greater > than 32000. NFS v2 implementations using a 16 bit signed value for uid_t. Such implementations exist because uid_t must be able to represent -1 as an error condition. > There are a couple of user id's in our system defined in the 64000 > range (notably the nobody user) and I was wondering if this infers > additional/reduced priviledges. No. There is no bit-decoding of uid_t values, other than reserved values. The user "Nobody" is generally UID -2, represented as 65534. The user "Nobody" will show as an error if the program is testing with: uid_t result; ... if( result < 0) vs. testing with: if( result == -1) So it is minorly significant, mostly for buggy programs, or programs which specifically disallow "Nobody" and other "reserved range" user ID's. Note that these programs which specifically disallow such users by value fail in the presence of 32 bit uid_t; for historical reasons of interoperability with remote systems, uid_t should be treated as a signed 16 bit value wherever possible. Expectations of special "negative", non-minus-one, "token" values for UID's means that the program is also buggy (for what that's worth)... meaning all compares for "cheating" programs should be explicitly "-1" or "(uid_t)65534" instead of "< 0". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707071835.LAA18117>