[1959] in Kerberos_V5_Development
Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Nov 13 13:59:51 1996
Date: Wed, 13 Nov 1996 13:59:26 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, tlyu@MIT.EDU, krb5-bugs@MIT.EDU,
krbdev@MIT.EDU
In-Reply-To: Tom Yu's message of Wed, 13 Nov 1996 13:25:44 -0500,
<9611131825.AA27526@tesla-coil.MIT.EDU>
Date: Wed, 13 Nov 1996 13:25:44 -0500
From: Tom Yu <tlyu@MIT.EDU>
The change in the default keytab name in and of itself is not that
great a problem in my opinion, since it can be overridden if
necessary.
There are indeed two separate problems here. This is problem #1,
whether or not we change the default keytab name from /etc/v5srbtab to
/etc/krb5.keytab. This is one of those things that we can only do now,
and not after 1.0. I would have wished that we fixed this *before*
feature freeze, but nevertheless this a change that if we want to do it
at all, we have to do it now.
The problems resulting from the attempt to eliminate global variables
are more indicative of design flaws in kadmind. I would rather not
back out the changes completely, since I believe that they are a
necessary thing in the long run. I imagine that either setting the
appropriate environment variable before calling the gssapi-krb5 layer,
or creating a new global variable with an name like
krb5_kludge_ktname, would solve the problem at hand.
This is problem #2. Here I have to side with Barry; trying to fix this
a bad idea. We can surround all instances of the use of the global
variable with "***internal interface*** DO NOT USE" comments, but we
should keep the global variable interface for now. This is the
safest way to avoid any unanticipated problems (such as the one you
luckily discovered in the kadmin interfae).
The design flaws aren't in kadmind, but rather have to do with an issue
of what services are supported by the GSSAPI; specifying the keytab name
is a mechanism-dependent issue which the GSSAPI doesn't support.
Furthermore, getting the context used by the GSSAPI also isn't
supported. One can imagine all sorts of ways of fixing this, but there
are some real API design issues here.
- Ted
