You wrote:
...
> To elaborate:
>
> Here's the output from "tokens" after I've klog-ged:
>
> User's (AFS ID 1001) tokens for [EMAIL PROTECTED] [Expires Feb 9 21:23]
>
> And here's the output after I've run gettoken on a srvtab:
>
> Tokens for [EMAIL PROTECTED] [Expires Feb 6 03:32]
>
> Two things are different in the second case: the AFS ID is absent, and
> the token expiration is 12.5 hours away instead of the 100 hours that
> my particular ID is entitled to. (The first I can understand; there's
> no requirement for a principal in the kerberos server to be in the PTS
> database.)
gettoken just stuffs a ticket for AFS into the kernel.
The stuff it sticks in with the ticket differs slightly from
what current AFS versions of klog supply; that is why the
output from the "tokens" command differs.
There isn't any validation for what gettoken/klog stuff in;
you could literally supply *any* AFS ID there, and it would work.
The cache manager never uses the ID supplied there, instead, it
(apparently) lets the file server do all permission checking.
>
> So either I need a gettoken modified to get an AFS ID at the same time
> as it gets a token, or I need another way to find out what principal
> the current process has been authenticated as. Either way, I would
> also like a way for the token obtained via the srvtab to have the
> lifetime that the authentication server has associated with it.
Parsing the output from "tokens" is wrong; because a malicious
user can supply any parameters they desire. Unfortunately, it is
not simple to figure out who a token really belongs to. The
only real way you can do is is to have a process, running on an
AFS server (and that hence has access to the key of afs) to decode
the ticket, and return some sort of authenticated notion that the
ticket really belongs to the person in question. Once upon a time,
(apparently) the AFS file servers could do this ("RXAFS_CheckToken");
unfortunately, modern file servers will instead return ECONNREFUSED,
so this isn't useful. It would be convenient if ptserver had some such
interface, but I don't see one present.
It is also ugly to use a uid range. It would be far better to
check to see if the user is a member of some specific protection
group. This will give you considerable additional administrative
flexibility.
So, the straight-forward approach to use the token to validate
a user's identity:
(1) write something to run on the database servers that uses a
token and returns the identity of the person in question.
Ideally, instead of just returning the person's UID, it would
do a "getcps".
(2) Use "klog.krb", get a regular MIT style tgt, & use it to
communicate with a server (which doesn't necessarily have the
key of afs) that could in turn do a "getcps" (if desired).
Oh yes, there's a 3rd choice - believe the UID that's
stuffed into the kernel. Since this can only be set by
certain administrative programs (ie, login), this should
normally be whatever value is in the password file, which
is perfectly adequate security if what you're trying to secure
is data that's stored on the local machine. If you are
instead trying to secure a network resource, you may want
to think through your security model very carefully.
-Marcus Watts
UM ITD PD&D Umich Systems Group
