Talking about tokens.

[Chris Wing]

Per:

> I have more than once been annoyed by the behaviour of the `tokens` and
> `klist -T` commands in how they present the identity information
> associated with the token. It gives the (AFS ID somenumber) which often,
> if I do strange things, is strictly incorrect.

The AFS ID is currently only set properly if you use the 'klog' program to
get a token. Otherwise, it will be set to your current UID. Note that
there is a cost to getting the "right" answer-- we have to set up a rx
connection to the cell's database server and look up the information.

> For example, if I get tokens on my linux-box where my uid is 500, then the
> AFS ID somenumber will be 500. This is not correct. The AFS ID associated
> with the token is another number.

Is this using klog or using another program?

> There are numerous other games you can play with tickets and tokens
> and the tramsarc-client too is badly confused and the information. One
> other funny example is if I get tgts in a ticket file, su another
> user, copy the ticket file and afslog.

'afslog' is not a Transarc command, so you shouldn't expect it to work the
same as Transarc's :)

> Then the AFS ID presented from klist -T or tokens will be the uid of
> the su`d user, but the tokens, if you try using them, are obviously
> the right ones (anything else would be a very bad security breach of
> kerberos/afs).

'afslog' can only get tokens based on the Kerberos TGT that you already
have. But as noted previously, 'afslog' will not get the proper AFS ID
anyway.

> I would like the klist -T and tokens commands to present the AFS ID as
> user.instance at realm. This information is obviously there somewhere (in the
> runing arlad) since otherwise it could not produce an authenticator to
> send to the afs server (I am way out on thin ice here).

Actually, the information you want (textual representation of the user) is
lost once the token is created. Only a Kerberos credential is actually
used when sending authentication to the remote server. As a hack, I can
have the 'tokens' program look up the names given the AFS ID. This would
do what you describe, at the cost of requiring a network lookup.

The klist program will not be able to do this, at least for the near
future, because it's part of kth-krb, not Arla.

> Is this a good idea, or are there strong arguments against? We would not
> by default behave the same (in my opinion broken) way as transarcs tokens,
> but is that important?

I think that behaving the same as Transarc by default is a good
thing. Otherwise, people familiar with their client will get confused when
they use Arla. This is why I wrote klog, tokens, and unlog in the first
place.

We can add a new flag to tokens that does what you describe, if you like.


-Chris Wing
wingc at engin.umich.edu