[1683] in Kerberos-V5-bugs
Re: appl/bsd/login.c smashes TZ environment variable
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Oct 21 21:42:41 1995
To: Marc Horowitz <marc@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, krb5-bugs@MIT.EDU, epeisach@MIT.EDU
In-Reply-To: Your message of "Sat, 21 Oct 1995 18:52:06 EDT."
<9510212252.AA24646@portnoy.MIT.EDU>
Date: Sat, 21 Oct 1995 21:42:36 EDT
From: Sam Hartman <hartmans@MIT.EDU>
> From: Marc Horowitz <marc@MIT.EDU>
> Content-Length: 1937
>
> >> 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.
Unfortunately, it isn't clear that this is possible in this
instance. For example, consider getting initial tickets. If a higher
level application wanted to use a simple interface, it would not be
able to deal with complex issues like determining how to get
additional information from a user for preauthentication. This user
interaction clearly doesn't belong in a Kerberos library, because it
is highly dependent on the user interface of the application; using
stdio in an X application is unaccptable.
On the other hand, the higher level login application cannot
ignore these issues, or preauthentication will not be usable in the
real world because the login programs will not be able to get the
additional information needed for it to work. You can't make the
abstractions simpler than the complexity mandated by the problem you
are solving.
--Sam
