On Monday, March 20, 2006 01:19:08 AM -0800 "Henry B. Hotz"
<[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
