[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: AFS tokens
From:       Marcus Watts <mdw () umich ! edu>
Date:       1993-12-02 4:38:56
[Download RAW message or body]

> Date: Tue, 30 Nov 1993 16:31:09 -0700 (MST)
> From: Brent Dunlock <DUNLOCK@ACVAX.INRE.ASU.EDU>
> Subject: AFS tokens
> To: netatalk-admins@umich.edu
> 
> I'm running netatalk-1.3b2 with AFS.  The AFS client is a SUN running 4.1.3.
> Everything works fine for about two minutes, then it acts like I lose my AFS
> token and hence, access to all my files in AFS.  
> 
> For example, I'll choose my server from a MAC and log in with the kerberized
> UAM, double click and see all my files.  I can even copy files from AFS space to
> my MAC and back.  Then, poof - suddenly I can't access my files any more.  The
> ticket lifetime set for my account is well beyond the 25 hours default (set to
> like 280 hours for this account).  
> 
> Any clues to this mystery would be appreciated!
> 

The copy of netatalk you use must have been built with some
kerberos library.

If you have source to this library, you should check out get_ad_tkt()
in src/lib/krb/get_ad_tkt.c and src/lib/krb/lifetime.c.  In the former,
you want to make sure that
    lifetime = (unsigned char) ptr[0];
and NOT!
    lifetime = ptr[0];
If you see the latter, you have a very ancient kerberos library.  Get
a more recent copy & try again.  If you don't have the lifetime.c
file, you don't have the "lifetime" fix for kerberos.  The original
version of kerberos stored lifetimes in 1 byte, in 5 minute increments,
allowing for a maximum token lifetime of about 21 hours.  The lifetime
fix maps values larger than 128, into a non-linear set of successively
much larger values.  In any event, you'll want to get a more recent copy
if you are missing the "lifetime" fix.  Your transarc representative
may be able to help you more with this.

There is no published AFS cell anywhere under the 129.219 network
or for asu.edu.  I presume you either don't publish your AFS cell, you've
cleverly hid your cell somewhere else, or you're using somebody
else's AFS cell.  In any event, I can't tell if you're running Transarc's
kaserver or MIT's kerberos server.  So I can only give you this unlikely
but possible cause of error: if you're running the MIT server on a byte
swapped (intel or dec) machine, that *may* be exercising some sort of byte
swapping bug, -- also, the pw change facility in netatalk & the UAM won't
work.

Here's some points where a syslog or so in afpd should narrow
the problem and perhaps point to the culprit (be it afs, krb, netatalk,
or the UAM.)

In etc/afpd/kuam.c, in kuam_get_in_tkt, there is a line
that reads:
    *(pkt->dat+(pkt->length)++) = (char) life;
the value of "life" here would be interesting (it should be 255).
If it isn't, look to krb_login for the fault.

In etc/afpd/kaum.c, in kuam_set_in_tkt, there is a line that
reads:
    lifetime = (unsigned char) ptr[0];
the value of lifetime here is interesting as well.
For a ticket lifetime of 280 hrs, a value of about 177
would be right. (this value, minus 128, is an index into the array
in krb/lifetime.c.  If you don't have lifetime.c, then that's one
good reason why your kerberos library could be screwing you.)
If this value is very small (ie, obvious trash), then
the fault may lie in bad data the UAM returned, or in
bad decoding in kuam_set_in_tkt itself.

In etc/afpd/auth.c, in krb_logincont, there is a line that reads:
    ct.EndTimestamp = cr.issue_date + ( cr.lifetime * 5 * 60 );
the value of EndTimestamp is when the afs cache manager thinks
your token will expire, and so that value, as well, is interesting.
It should be some time significantly in the future.  cr.lifetime here
should be 177 as well.  It would also be worth checking that
issue_date is actually the present +/- a few seconds.

	Beware: this is NOT when your token REALLY expires.  If you set
	this value to some larger value, very Bad things will happen;
	the calls to the file server will fail, and your cache manager
	will decide the file server has !GONE DOWN! instead of expiring
	your tokens.  This is Not A Good Thing.

As it happens, this formula is wrong, because it's not using the
kerberos lifetime fix.  So, it will actually result in artificially
low token lifetimes.  The correct statement would be:
    ct.EndTimestamp = krb_life_to_time(cr.issue_date, cr.lifetime);
Undoubtedly, a future release of netatalk will contain this minor fix.

				-Marcus Watts
				UM ITD RS Umich Systems Group

[prev in list] [next in list] [prev in thread] [next in thread]