Coda File System

Re: none

From: Ivan Popov <>
Date: Wed, 18 Feb 2004 10:36:34 +0100 (MET)
On Tue, 17 Feb 2004, Jan Harkes wrote:

> The problem is that kerberos might go off and do something like a
> blocking DNS lookup, or long computation without yielding control to
> other LWP threads. This isn't much of a problem in clog and auth2, but
> for Coda clients and server such a thing would be deadly as it leads to
> disconnections. And then we have to reestablish the RPC2 connections
> which requires authentication which might block in kerberos, which leads
> to disconnections...

It relates not only to Kerberos, but to gss-api as well.
Reading :
For mech_types which require interactions with third-party servers in
order to establish a security context, GSS-API context establishment
calls may block pending completion of such third-party interactions.

Still, for token acquisition, gss-api can be a nice wrapper for several
authentication types, possibly including Kerberos (though incompatible
with the existing Kerberos support).

Given a modular clog, one source could be linked with different gss-api
libraries to produce several corresponding modules.

Mark Phalan wrote:

> I have been working on adding GSS-API authentication to auth2 and clog -
> it uses GSS-API to authenticate and then wrap the coda tokens for the
> client who can unwrap them and use them. I haven't looked at what venus
> does with those tokens (in fact I don't really have a clue) but at least
> the authentication part is basically there.

Mark, would you mind to share your code?

Jan, I would volunteer to add gss-api (krb5 and gsi) to the modular clog
suite... should be pretty much straightforward.
(I assume you did not touch that code and no coordination of changes is

Received on 2004-02-18 04:41:53