From owner-freebsd-hackers  Mon Jul  7 11:40:31 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA00153
          for hackers-outgoing; Mon, 7 Jul 1997 11:40:31 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA00145
          for <FreeBSD-hackers@FreeBSD.ORG>; Mon, 7 Jul 1997 11:40:29 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA18117; Mon, 7 Jul 1997 11:35:47 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199707071835.LAA18117@phaeton.artisoft.com>
Subject: Re: uid > 32000
To: tholmes@zeus.leitch.com (Tony Holmes)
Date: Mon, 7 Jul 1997 11:35:47 -0700 (MST)
Cc: FreeBSD-hackers@FreeBSD.ORG
In-Reply-To: <199707071557.LAA01700@bitter.zeus.leitch.com> from "Tony Holmes" at Jul 7, 97 11:57:48 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 	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.