Hi Greg,

On Mon, Jul 10, 2006 at 08:01:02AM -0400, Greg Troxel wrote:
> > I can not log in to my environment directly, as it depends on things under
> > my $HOME, so I am forced to login in two steps, first "failsafe" or on
> > an alphanumeric console, forge a token, then log in as usual.
> > In connected mode I am forced into doing clog the same two-step way.
 ...
> MIT Athena had to deal with this with AFS, which had homedirs there.
> There, you logged in via Kerberos and the login program did aklog
> (which is like clog with kerberos).   I have long thought that Coda
> should just user Kerberos and not have its own local crypto.  But, the

Kerberos is more than just crypto, and unfortunately not exactly what is needed
for a file system. Using a wrong tool would cripple Coda's design.
Then Coda would most probably end where AFS is now, asking for changes
in Kerberos to incorporate features for Coda's sake...

You see, Kerberos is heavily relying on each client host being
configured. Coda does not need any client host configuration with respect to
how the users authenticate (even simultaneously) against different Coda realms.

Coda is also capable of using multiple and different authentication means,
even existing maintained by somebody else databases. As such, it is
trivial to add Coda services to an existing infrastructure.

Kerberos was designed for site-wide usage, not global one.
AFS is behind Coda with respect to globality, partly due to its
tight dependency on Kerberos.

Kerberos can potentially be used in a way compatible with a global file system
needs, but do not forget that it (Kerberos) is being used for other things
as well. The other applications dictate their own setup "best practice".
Let alone the already existing Kerberos realms, each built on different
premises.

> new RPC code with being able to get tokens via kerberos is mostly
> equivalent (except that there's a lot of code and protocol that hasn't
> had adequate review).

Indeed, the code would profit from more reviewers.

Regards,
Rune