[OpenAFS] Future of AFS? Interesting Ideas!?

[Chaskiel M Grundman]

--On Wednesday, December 25, 2002 12:24:29 +0100 Turbo Fredriksson 
<turbo@bayour.com> wrote:

> hooks. As long as the possibility is there, any site can do whatever they
> please. Just provide a 'decent' default.
Hooks in what?

The rpc system does have "hooks" to support semi-arbitrary secret-key
based authentication schemes, but significant amounts of code have to be
written to support each one. (actually, the rx security class mechanism is
more limited than it was probably intended to be; it only supports a single
round trip for the authentication exchange, can only pass a limited amount
of data in that round trip, and relies on the client being able to know the
session shared-secret before the authentication exchange has occured. This
can be worked around, so it's not going to prevent kerberos5 from being
used)

The cache manager and most of the utilities already have what I consider to
be good enough "hooks": they don't care where your authentication comes
from, as long as it ends up resembling kerberos 4 tickets that are handed to
the kernel via ktc_SetToken or the like.
gssklog from anl does exactly this for the authentication acquired
from a globus system

The only things that are really dependent on the kaserver interface are
klog, login, and the pam module. If you don't want to use the kaserver,
then ignore those tools.

> Always? From what I can tell, the 'aklog' etc isn't THAT old...
There's been a kerberos 4 aklog for quite a while:

 * $Id: aklog.c,v 1.3 91/07/16 06:25:13 probe Exp $

heimdal and kth-krb include support for dealing with afs tokens,
and unlike aklog, do so without being dependent on the AFS code.
It can't be done the other way around without a dependency, and
the openafs elders and/or gatekeepers have not yet decided to allow
openafs be dependent on external packages to build and/or work.

If your problem is with the documentation, then join the club. This
documentation is being distributed because it's much better than
nothing at all, and the documentation effort is having problems
getting people involved (imagine that) ,not to mention that it will
have to start almost from scratch, since the source for the IBM
documentation apparently cannot be found)

> but this should be the case with the (ubik)(?). I (want) LDAP, so
> I'd like the possibility to do this...
LDAP is a whole other problem.

pts isn't a directory service

LDAP does not (yet) make a good authorization service.
Not even microsoft uses it that way.