Ticket History #182: /etc/v5srvtab -> /etc/krb5.keytab

From tlyu@MIT.EDU Tue Nov 12 18:20:21 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id SAA28782 for <bugs@RT-11.MIT.EDU>; Tue, 12 Nov 1996 18:20:20 -0500
Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP
id AA25420; Tue, 12 Nov 96 18:20:19 EST
Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA17078; Tue, 12 Nov 1996 18:20:18 -0500
Message-Id: <9611122320.AA17078@tesla-coil.MIT.EDU>
Date: Tue, 12 Nov 1996 18:20:18 -0500
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: /etc/v5srvtab -> /etc/krb5.keytab
X-Send-Pr-Version: 3.99

mit

System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc


Currently we're using a somewhat bogus name for the default
keytab, namely /etc/v5srvtab. It should be something that doesn't
refer to the word "srvtab", since that gets mapped to krb4 in many
people's minds, not to mention program doc strings. I propose the
name /etc/krb5.keytab.

Additionally, the default keytab name is currently a global
variable in the library. This should be fixed.




Responsible-Changed-From-To: krb5-unassigned->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Tue Nov 12 18:22:47 1996
Responsible-Changed-Why:
I'm implementing this.

State-Changed-From-To: open-feedback
State-Changed-By: tlyu
State-Changed-When: Wed Nov 13 03:44:13 1996
State-Changed-Why:
Mostly dealt with.


From: Tom Yu <tlyu@MIT.EDU>
To: krbdev@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 03:46:50 -0500

Ok I've mostly implemented and checked this in. In the process of
implementing this change, I've added a krb5_kt_set_default_name()
function that will change the default keytab name in the context, and
cause the default keytab name to get stashed in the context. This
eliminates yet one more global variable from the kerberos library.

While we're at it, we should try to punt the rest of the global
variables from the libraries, but this is likely to be a post-1.0
issue.

---Tom

From: Tom Yu <tlyu@MIT.EDU>
To: krbdev@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 12:28:23 -0500

We have a serious problem. ovsec_kadmd.c was relying on the old
global variable mechanism (krb5_defkeyname) to set the default keytab
name for the gssapi/krb5 layer. This violates abstactions right and
left. It's causing the dejagnu tests for kadmind to fail, since after
all the context used by the kadmind is different than that used by the
gssapi layer. Anyone have any bright ideas on this subject? For that
matter why are the kadm5 tests passing?

---Tom

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 12:29:48 -0500

For the record, I strongly object to the fact that such a
user-significant change was made this close to 1.0 with no public
design discussion and while there was still significant disagreement
among the subset of people that you did talk to about it, and without
sufficient testing.

I recommend that we back out these changes and, if we don't, I
guarantee that we will regret it.

Barry


From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krbdev@MIT.EDU, krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 12:53:41 -0500

ovsec_kadmd.c was relying on the old
global variable mechanism (krb5_defkeyname) to set the default keytab
name for the gssapi/krb5 layer. This violates abstactions right and
left.

If I recall properly, kadmind sets krb5_defkeyname because there was
no other way to specify the keytab that the GSS-API krb5 mechanism
will use to accept a context. Perhaps now we can use KRB5_KTNAME, but
that environment variable did not exist when kadmind was implemented.
I'm not sure how that interacts with secure/unsecure contexts, nor
which kadmind is using.

For that matter why are the kadm5 tests passing?

The client-side kadm5 tests use a credential cache, not a keytab, to
authenticate to kadmind. The server-side kadm5 tests do not use any
Kerberos authentication at all. So, neither set of kadm5 api tests
need to specify a keytab to use.

Anyone have any bright ideas on this subject?

Yes, I do. Back out your changes and leave them for post-1.0.

Barry

From: Tom Yu <tlyu@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: tlyu@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 13:25:44 -0500

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.

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.

---Tom

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tlyu@MIT.EDU
Cc: tlyu@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 13:47:15 -0500

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.

It is not a critical change. No one is complaining about it. No
functionality is lost with the current name. The only "problem" is
that v5srvtab is remniscent of the V5 name. Who cares? Furthermore,
if it is so easy to change smoothly, then we can change it in the
future.

There are *many* things that really ought to get done before 1.0 goes
out that are not going to get done. The most important thing for 1.0
is that it goes out on time, in working order. As has already been
demonstrated, your change made the code stop working. So you've
already found one thing you missed... might there be others? Might we
find them only after 1.0 is released?

I would rather not
back out the changes completely, since I believe that they are a
necessary thing in the long run.

Invalid argument. Think "feature freeze." See the previous
paragraph.

or creating a new global variable with an name like krb5_kludge_ktname

That's exactly what we had before, no?

Barry

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
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 13:59:26 -0500

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

From: Tom Yu <tlyu@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: tlyu@MIT.EDU, krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 14:06:09 -0500



Getting the name change out before 1.0 will mean that we won't change
it after the 1.0 release, thus removing the requirement that people
change their keytab locations after 1.0. I believe this is a win.

Anyway I do not think we should be tempting people to use global
variables in the library. Removing the usage of the global variables
before 1.0 means that no one will write code using them. If we remove
the usage of the globals after 1.0, then people who assume that the
global variables are part of the API will lose when we do remove them.
Perhaps it is enough to leave the variable in and remove any
documentation refering to it, and comment everywhere we use it to
indicate that it is Just Wrong.

---Tom

From: Tom Yu <tlyu@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>, "Barry Jaspan" <bjaspan@MIT.EDU>, krb5-bugs@MIT.EDU,
krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 1996 14:43:00 -0500

Anyway, I'm in the process of backing out all of the changes except
the name change. I can then check in the experimental changes on a
branch to be hacked on later.

What do people think the keytab name should be under DOS?
krb5.keytab doesn't fit with an 8.3 naming scheme, so how about
k5keytab?

---Tom

From: Jeff Bigler <jcb@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Wed, 13 Nov 96 15:47:25 -0500


Or how about krb5.kt?

Jeff

State-Changed-From-To: feedback-open
State-Changed-By: tlyu
State-Changed-When: Thu Nov 14 02:20:07 1996
State-Changed-Why:
This is a doc bug now.


From: Tom Yu <tlyu@MIT.EDU>
To: krbdev@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Thu, 14 Nov 1996 02:19:25 -0500

Global variable removal has been backed out, pending post-1.0 design
work. Unix keytab name defaults to /etc/krb5.keytab; DOS keytab name
defaults to krb5kt (to match krb5cc). Still needs to be documented
though. I guess I can do that as well.

Also, I added comments to the library and functions referencing the
particular bad global, basically to the effect of "if you use this
global you will lose".

---Tom

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tlyu@MIT.EDU
Cc: krbdev@MIT.EDU, krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/182: /etc/v5srvtab -> /etc/krb5.keytab
Date: Thu, 14 Nov 1996 10:55:16 -0500

Global variable removal has been backed out, pending post-1.0 design
work. Unix keytab name defaults to /etc/krb5.keytab; DOS keytab name
defaults to krb5kt (to match krb5cc). Still needs to be documented
though. I guess I can do that as well.

Yes, it definately needs to be documented, or there are going to be 75
messages on the Kerberos list asking "why is 1.0 reporting 'keytab not
found'?".

In install.texinfo, there is a node Installing Kerberos V5->Installing
KDCs->Upgrading existing Master and Slave KDCs to the current
release. Probably what you should do is add an Upgrading node to the
top level menu so it looks like


Under that top-level menu entry, put the upgrading KDCs node I already
wrote, and add another section on the keytab name change.

Also make sure the keytab name relation is documented in the krb5.conf
man page, the new default value is documented, and mention that the
old default changed and how to fix it.

Barry

State-Changed-From-To: open-closed
State-Changed-By: tlyu
State-Changed-When: Fri Nov 15 00:09:37 1996
State-Changed-Why:
I believe I have fixed all the relevant documentation, including
krb5.conf.M and install.texinfo.