[OpenAFS] rxkad error=19270410 on AIX 5.3, openafs 1.4.2

[Marcus Watts]

Various wrote:
> Message-ID: <4571F7AB.2040802@lehigh.edu>
> From: Steve Roseman <sgr0@Lehigh.EDU>
> To: jaltman@secure-endpoints.com
> Cc: openafs <openafs-info@openafs.org>
> References: <4550BA08.9070201@secure-endpoints.com> <456D34DD.1010406@secure-endpoints.com> <45704CBE.3090502@lehigh.edu> <Pine.GSO.4.61-042.0612011409250.5023@johnstown.andrew.cmu.edu> <4571F2B3.6020606@lehigh.edu> <4571F54D.20608@secure-endpoints.com>
> In-Reply-To: <4571F54D.20608@secure-endpoints.com>
> Subject: Re: [OpenAFS] rxkad error=19270410 on AIX 5.3, openafs 1.4.2
> Date: Sat, 02 Dec 2006 17:01:15 -0500
> 
> Jeffrey Altman wrote:
> > Steve Roseman wrote:
> >> Derrick J Brashear wrote:
> >>> On Fri, 1 Dec 2006, Steve Roseman wrote:
> >>>
> >>>> I can get a token, but it errors when trying to access AFS filespace:
> >>>>
> >>>> $ klog
> >>>> Password:
> >>>> $ tokens
> >>> Try the patch I committed yesterday to src/rxkad/private_data.h
> >> I assume the one with:
> >>
> >> !     afs_int32 ticketLen;      /* length of ticket */
> >>
> >>     No dice...
> >>
> >> $ klog
> >> Password:
> >> $ cd /afs/cc/home/lusgr/private
> >> afs: Tokens for user of AFS id 258 for cell cc.lehigh.edu are discarded
> >> (rxkad error=19270410)
> >> ksh: /afs/cc/home/lusgr/private: Permission denied.
> >>
> >> Thanks,
> >> Steve
> > 
> > One of the scenarios that can cause this error is if the key that the
> > client is using to encrypt the checksum data is different from the key
> > the server is using the decrypt it.
> > 
> > This could happen if for a given kvno the key in the KDC is different
> > from the key stored in the server's KeyFile.
> > 
> > Is that a possibility?
> 
> 	No.  We're still kaserver only.  (Maybe that's the problem, but let's 
> not go there...) And this is the only client I've ever seen with a 
> problem like this.  And the first AIX 5.3 system I have tried it on.
> 
> Steve
> 
> > Jeffrey Altman
> > 
> 
> 
> -- 
> ----------------------------------------------------------------------------
> Stephen G. Roseman
> Lehigh University
> sgr0@Lehigh.EDU
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

For what it's worth, I've discovered that I have what appears to be
the identical problem here with some test machines at umich.

I'm sure this is not a bad server key problem.  I can reproduce
it on several cells - so the only common factor here is the aix
cache manager.  Those same cells work perfectly from other clients
using regular linux.  Secondly, the very same ticket that fails when
used with the cache manager, works perfectly with userland tools such
as "pts" on the very same machine moments before.

	In my case: aix client is:
		aix 4.3 (4330-10)
		openafs 1.5.10 + patches, mit krb5 1.5
	test cell I'm using for most of this:
		openafs 1.5.10 + patches, mit krb5 1.5
		(and it's a one machine cell, - not much chance
		of keyfiles being out of sync.)

I've captured the challenge/response/[failure] for a success
and failure case and decoded and decrypted the bits - I can tell
that it's definitely a problem with the cache manager doing
something bad encrypting the v2 response.  I can certainly post
the data I've got if anyone wants to see the actual bits.

I haven't yet managed to actually try an int32 ticketLen, but
I'm having a lot of trouble understanding why this would help.
The claim is that the ticket schedule ends up misaligned - I could
see that core-dumping on sparc, but powerpc can do unaligned
fetches so I'm not sure how that would matter (except maybe speedwise).
If different code is compiled with different alignment options, I could
see a problem - but there isn't much code that knows about struct rxkad_cprivate,
nor do I see any obvious use of alignment options or pragmas.
I certainly can't argue if this in fact did fix the problem, but
I gather from Steve's report above that it doesn't.

It would be helpful (to me at least) if Steve Roseman could
verify that "pts" and other tools work.  That would be useful
confirmation that it's the same problem I see.

				-Marcus