[OpenAFS] clientName.name: AFS ID v. UNIX UID

[Marcus Watts]

David Botsch <dwb7@ccmr.cornell.edu> wonders:
> Delivered-To: openafs-info@openafs.org
> From: David Botsch <dwb7@ccmr.cornell.edu>
> To: openafs-info@openafs.org
> Message-ID: <20030612223932.GA2039@domino.ccmr.cornell.edu>
> Date: Thu, 12 Jun 2003 18:39:32 -0400
> 
> I have noted in afs source code for tokens.c that clientName.name can 
> take the form AFS ID XXXX or Unix UID XXXX or some other forms.
> 
> What makes the determination on which one of these forms it takes and 
> what does this mean?
> 
> Thanks!

The short answer is "it doesn't mean a thing".

The longer answer is that the logic in log/tokens.c is actually driven
by logic in auth/ktc.c which is where "aclient->name" gets filled in
with with ct.ViceID.  There's an even-oddness kludge that drives this.
ct.ViceID comes from the cache manager, but the cache manager doesn't
actually use this for anything useful (apparently not even error
messages).  The cache manager is actually just returning the token that
some other program, such as klog, login, or aklog stuffed into the
kernel.  So it's actually that program that drives which message you
see.

The reason why the "ID" doesn't matter is that the only thing that
really determines your file access is your username in your ticket, and
what the fileserver gets back from ptserver when it does a "GetCPS" on
that username.  The cache manager never sees this exchange, and
certainly doesn't have a way to lie about it.

aklog (at least some versions) has a flag -noprdb that turns off the
"AFS ID" lookup; the main result without this is that aklog runs
slightly faster.  So that's an easy way to experiment with the
difference such as it is.

				-Marcus Watts
				UM ITCS Umich Systems Group