[1682] in Kerberos-V5-bugs
Re: appl/bsd/login.c smashes TZ environment variable
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sat Oct 21 18:52:16 1995
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, epeisach@MIT.EDU
Date: Sat, 21 Oct 1995 18:52:06 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> I was talking to Richard about this on the 15th, and we
>> realized that if the ticket-getting interface were done well, it could
>> probably be moved into libkrb5.
Perhaps not *everything* should be in libkrb5. It's too damn big
already.
I argued before the beta5 was released that there should be a few
libraries. The first would implement protocol primitives. As far as
I can think of, this could be entirely reentrant, since the protocol
itself is stateless, and mostly portable (with some exceptions). The
old libkrb5 API was mostly this kind of function, plus a set of
higher-level convenience functions. There should be a second library
which implements what we've got in beta5 now: reentrant (via use of
contexts) convenience functions which are most useful to application
writers, and include functionality like credential caches, keytabs,
replay caches, etc.
Functions which do complex, policy-dependent stuff such as
preauth-handling, "login" initial-ticket handing (including checks
against a keytab, perhaps password-expiration support, and whatever
else people come up with), etc should clearly be in a third library.
>> Unfortunately, it's difficult to develop a simpler interface without
>> losing functionality; if someone ever tries to do a good job of
>> integrating preauth--something that IMHO should happen--this simpler
>> interface could easily get in the way.
Which is why having a few different abstraction boundaries is a good
idea. The simpler interfaces can be consumed by higher-level
applications which don't need as much control over the details, while
routines or applications which need more control can reach into the
lower levels of the abstraction. This is sort of like the difference
between using POSIX I/O or ANSI I/O, or between Xlib and Xt.
Marc
P.S. Yes, this will take resources, but I suspect this will happen
anyway. We might was well plan on it and minimize the pain.
