[OpenAFS] Re: OpenAFS 1.6.5/1.6.10 - server segfaults during migration to rxkad-k5

Andrew Deason adeason@sinenomine.net
Fri, 7 Nov 2014 11:15:41 -0600


On Fri, 07 Nov 2014 17:46:19 +0100
Volkmar Glauche <volkmar.glauche@uniklinik-freiburg.de> wrote:

> mit-krb5# ktutil
> ktutil:  rkt /etc/openafs/server/rxkad.keytab
> ktutil:  l
> slot KVNO Principal
> ---- ----
> ---------------------------------------------------------------------
>    1    0 afs/cell@REALM
>    2    0 afs/cell@REALM
>    3    0 afs/cell@REALM

It seems likely the 0 kvno is the problem. We only copy in a principal
if the kvno in the keytab is greater than 'vno' in
akimpersonate.c:pick_principal, which starts out at 0. I assume that's
valid and we just hadn't encountered this yet? You should be able to
workaround it by just bumping the kvno and re-extracting it, so you get
a higher kvno. (Or you can just change the kvno in the keytab -- they
don't have to be correct -- but that's confusing and don't do that.)

I'm not sure if I'll be able to submit a fix before tomorrow; someone
else feel free to submit one if you want something today and have the
time.

> As I already said below, things seem to work fine with this
> rxkad.keytab and e.g. aes256-cts-hmac-sha1-96 tokens if the keytab is
> brought in place after the servers have been started.

Yes, that's because this code path is only hit when we retrieve
credentials to use for outgoing connections. That will happen when you
-localauth, or when you start up a server, but not if you add these keys
to a running server.

-- 
Andrew Deason
adeason@sinenomine.net