Coda File System

Re: More bugs in krb5.c!?

From: Jan Harkes <>
Date: Tue, 20 Apr 2004 13:52:32 -0400
On Tue, Apr 20, 2004 at 03:33:59PM +0200, Ivan Popov wrote:
> Hello Michael,
> > It seems as if there are still some bugs in krb5.c - as I just found
> > out, the realm specified in the conf-files is not used - it is
> > always determined from the hostname!

The realm in venus.conf is just a hint used by clog and cpasswd (and
au?) what the default 'Coda realm/cell' is whenever the user doesn't
specify one. It isn't even used by venus at all, in this respect venus
is totally realm agnostic.

As Ivan said, the Coda realm is more than likely not the same as the
kerberos realm. Here at CMU we're not using kerberos with Coda (yet),
but if we do we have several options, CMU already has a CS.CMU.EDU
Kerberos realm, as well as ANDREW.CMU.EDU. We could use CS.CMU.EDU for
both local login and for Coda authentication. But we should also allow
for cross-realm authentication for those people at CMU that do not have
a CS account. And then we might even want to set up our own CODA realm
to manage non-CMU users.

As you can see such authentication schemes are actually almost too
flexible. The is no single 'host -> kerberos realm' mapping, and not
even a clear 'coda realm -> kerberos realm'. How do we know what
kerberos tickets would be acceptable for which services on a host.

Ivan has been working on breaking up clog/auth2 into small modular
pieces, and one of the things he was working on was a way to get all of
this domain specific information available on a client. Coda has a
pretty straightforward way of mapping a Coda realm to a group of hosts.
This 'well known' group of hosts could run a service that can be queried
to discover availability (and configuration parameters) of the various
authentication mechanisms.

Given such information, a client can check it's environment to see if
any of the required information is already available i.e. an ssh-agent
might have a private key that we can use to authenticate with the realm.
Or we could have a usable kerberos ticket, or we can ask the user how he
wants to prove his identity.

Received on 2004-04-20 13:55:02