[OpenAFS-devel] More on aklog

[Ken Hornstein]

>We distribute source; Are they not particularly resourceful? Cell and 
>realm in control of different entities which can't play nicely? What? 
>Really, if you got screwed hard by this, either there are extenuating 
>circumstances, or being stuck inside a paper bag seems like it could be 
>your match...

It was a complicated situation (there was cross-realm involved, and the
person who got screwed wasn't really a programmer, so he had no idea
where to even start looking; all he knew was that when a KDC was
upgraded (not his), everything stopped working).  In his defense ...
how was he supposed to know about this?  Sure, there is the whole thing
about a "." being used as a V4 instance separator, and I wouldn't have
created principals named that way, but how was anyone who hadn't been
digging around in that code for years supposed to know this?  All he
knew was that he requested that principals got created, and he created
the same name in PTS, and it all worked fine for him.  He was sort of
indignant that a "strange Kerberos change" broke his AFS cell, and
looking back on it, I couldn't really blame him that much.

>> Yeah, it can lead to two principals being treated the same: so what?
>
>the obvious use would seem to be firstname.lastname; i suppose the surname 
>admin is uncommon; we have, however, had root as a surname here.

I think that's a bit of a red herring.  If you had a V4 infrastructure,
you'd never create a principal named "firstname.lastname".  If you were
V5-only, then you would expect that that the name would be simply
work in PTS, because you'd be depending on it working (and you'd be
REALLY screwed if you switched to V5 tickets from krb524d).  We have
a user who's surname is root as well, so I understand the possibilities,
but it's my feeling that if you didn't know enough about Kerberos to
understand this problem, you'd likely wouldn't know what an instance
_is_, and you wouldn't be creating principals with instances in them.

>> So far it's only seemed to cause
>> people problems,
>
>Because the people who haven't had any problems are busily reporting the 
>problems they don't have, I suppose...

Not sure I follow that.

>> because this _USED_ to work fine with krb524d,
>> which people used FOR YEARS without any problems, confusion or
>> security incidents.
>
>That you know of.

Sure, it's all ancedotal.  If someone wants to pipe up and say, "boy,
this code really saved my bacon", (and it's _not_ you :-) ) I'll shut
up.  It's hard to do a survey for this sort of thing.

>> The end result is that it's not a seamless
>> upgrade from a V4 ticket to a V5 ticket with krb524d, and that
>> sucks.
>
>A proposal of anything better than "well, 2 users could potentially be 
>treated as one" would be more entertaining at minimum.

My point here is twofold:

- This has been an generic issue with krb524d (not specifically for AFS),
  for a long long time.  If it was a problem in practice, I have to
  believe it would have popped up _somewhere_.  So either all of those
  peple out there with a last name of "root" have a lot more priviledges
  out there than they realize, or it's simply not a problem in the real
  world.
- There's an inconsistancy in how the AFS server and krb524d handle V5
  principal names.  You could argue that krb524d is wrong; I'd even be
  inclined to agree with you.  But the fact that they _don't agree_ is
  a problem.  I think one of them should change so that people don't
  get bitten by this in the future.

>Hey, I have a rotten idea, send a patch with aklog and some configure
>gunk, and slip in the reversion of this "change" with it.

Would you accept a patch to at least log the problem when servers
encounter it?  That sure would have helped us in tracking down the
problem quicker, at least.  I promise I won't commit it until after I
put aklog in the openafs tree :-)

--Ken