[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Jeffrey Hutzelman]

On Monday, March 20, 2006 01:19:08 AM -0800 "Henry B. Hotz" 
<hotz at jpl.nasa.gov> wrote:

> Just to be clear my desire is that OpenAFS provide a documented
> interface (like Heimdal kafs) that can be used by different people on
> different OS's to provide whatever hooks are appropriate to that OS.

OpenAFS provides a stable, documented API for examining and manipulating 
tokens and PAG's, in the form of the 'pioctl' and 'setpag' calls in libsys 
(if you'd rather not have Rx dependencies, you can use 'lpioctl' and 
'lsetpag' instead, but then you sacrifice the ability for your application 
to work correctly with an NFS translator).



> With all respect to Jeffrey, I think it is "not Mac" to have one part
> of the system showing you something that's inconsistent with another
> part.

Nonsense.  It is entirely appropriate to show you something you think is 
inconsistent if that is in fact the state of the system.  The only think 
"inconsistent" about having an AFS service ticket and no token is that you 
make the (false) assumption that you always have either both or neither. 
There are a wide variety of possible reasons for this to be untrue:

- failure to set tokens
- pagsh (i.e. changing PAG's without changing ccache's)
- changing ccache's without changing PAG's
- explicit klog
- explicit unlog (without kdestroy)
- explicit kdestroy (without unlog)


The Kerberos credential cache and AFS kernel token cache are _not_ the same 
thing, and you will do a lot better if you stop pretending that they are. 
There are lots of ways you can make your life convenient by automatically 
copying AFS tickets from a Kerberos ccache into the KTC, but it's still 
just copying.


Basically, you're asking for the UI to display something that is _not_ 
consistent with the state of the system, so you can pretend that things 
work differently than they really do.  A UI that hides confusing details is 
usually good, but a UI that outright lies to you (for example, telling you 
your ccache doesn't contain a particular ticket when really it does) is 
generally bad, especially when there are security implications.  Users need 
to know that security software isn't lying to them.


  I think a "typical" user neither knows, nor wants to know the
> distinction between the Kerberos ccache and the kernel token store.
> Therefore we owe it to them to make the distinction go away.

Uh, that does not follow.  Sometimes when the user's expectations are 
wrong, it's because their expectations are wrong, and we owe it to then to 
educate them.  No one is spending large amounts of time and effort to 
figure out how to change the way gravity works because they "owe it" to 
people who think a heavier body falls faster than a lighter one.


Now, unifying ccaches and the KTC is not quite as impossible as changing 
the gravitational constant of the universe, but it is still hard.  On some 
platforms, it might be within the realm of reason to make AFS use tickets 
directly out of the user's ccache instead of maintaining a separate KTC; on 
others, it would be flat-out impossible.  Even where it is possible, it 
would be a major behavioral change for people who expect to be able to 
change one without the other.


> Doing otherwise invites confusion, after all we're telling them we
> use Kerberos aren't we?

I don't know what you're telling your users.


> If you want to "fix" the problem by preventing the ccache from ever
> showing an afs service ticket, that's at least better than letting
> them be inconsistent.

No; that would be lying.



> To clarify that last a bit more:  I think getting/destroying tokens
> is a normal user operation that happens all the time.  Configuring
> the AFS client is something that the user may never do at all (if he
> gets a preconfigured installer for example).  They don't belong in
> the same GUI.

That much I'll agree with.


> OTOH getting/destroying Kerberos tickets probably
> happens as often (maybe exactly as often) as you muck with tokens.

Well then, maybe those operations _do_ belong in the same GUI.
However, tickets and tokens are separate objects and should be displayed 
separately.  The absense of one object (a token) should not result in the 
software hiding the existence of another object (a ticket).



> Just to bring another issue into the discussion.  What about if we
> use something besides Kerberos to get AFS tokens?

Then it turns out to be valuable not to inappropriately conflate Kerberos 
tickets and AFS tokens, doesn't it?


-- Jeff