32766 is indeed the "nobody" ID so far as AFS is concerned,
otherwise known as ANONYMOUSID in AFS aware C source.
In NFS, -2 was originally the "nobody" ID. It mutates into
65534 in later releases of SunOS, because SunOS only supports
16 bit UID's, & Sun made it unsigned at some point.
65534 is "two less than 2^16".
In Solaris 2.x, Sun made nobody into "60001", and added
a new "noaccess" UID - 60002. So that means the largest "real"
user ID in solaris can be 60000. Rumour has it that 2.5.1
relaxes this annoying restriction.
In AFS, they couldn't use negative numbers because those were
used for group ID's in PT. They couldn't use a number larger
than 32768, because that was pre unsigned UID's (in late
versions of SunOS), and besides, they were trying to support
other operating systems that might only have signed short UID's.
So, they apparently decided to use 32766 (two less than 2^15). I
guess it was a logical decision at the time.
In AFS, file ownership of newly created files is determined by
your credentials. What UID you happen to have on the local
workstation doesn't even enter into the picture - all the
file server sees is kerberos credentials. In order to determine
who to give files to, it looks the kerberos credentials up
against PT. If there weren't any credentials (because they
had expired, say), or the PT lookup fails, then the file
ownership of any files created would be to 32766, & the
acl's would have to allow creation of files by system:anyuser,
or in rare cases, at least system:authuser. Because of
the way this works, this ownership might also appear in rare
cases when your credentials weren't expired if, say, your PT
database or network were having serious trouble.
AFS doesn't have any other special positive user ID's.
It does recognize the following special group ID's:
SYSADMINID -204 system:administrators
SYSBACKUPID -205 system:backup
ANYUSERID -101 system:anyuser
AUTHUSERID -102 system:authuser
AFS also won't allow the ID of 0, at least, not in PT.
Probably this was a conscious design decision to discourage
AFS administrators from trying to administer a globally
shared root password across a whole campus which would
indeed be a significant scaling limitation, to say the least.
PTS groups, of course, will never appear on Unix file user
or group ownership.
A curious feature of the PT library (which is named libprot)
is that if a lookup in the PT database fails, then the call
still succeeds but the ID returned is the ANONYMOUS id.
This is to facilitate the operation of the NameToID
routine, which can lookup multiple names at once.
If it returned an error, then none of the results
would be returned. Instead, it returns success, and
the special ANONYMOUS id code; and it's up to the
caller to flag this as a lookup failure, if indeed
it cares.
The credentials used in AFS file server calls depends on
if the process is a member of a pag, or what its UID is.
Each process that does not belong to a pag is treated
as being a member of a pag associated with that UID.
Hence, SUID programs may act differently, depending on
whether the process was pag'd or not. The "tokens" command
can be used to give a hint as to what credentials are
currently in use. Usually, it will claim that the credentials
belong to a particular AFS ID; but this ID has no necessary
connection with what the fileserver is going to see and use.
-Marcus Watts
UM ITD PD&D Umich Systems Group
