Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 13834 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 ; 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 >Number: 182 >Category: krb5-doc >Synopsis: /etc/v5srvtab -> /etc/krb5.keytab >Confidential: no >Severity: serious >Priority: high >Responsible: tlyu >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Tue Nov 12 18:21:01 EST 1996 >Last-Modified: Fri Nov 15 00:10:07 EST 1996 >Originator: Tom Yu >Organization: mit >Release: 1.0-development >Environment: System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc >Description: 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. >How-To-Repeat: >Fix: >Audit-Trail: 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 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 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" 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" 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 To: "Barry Jaspan" 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" 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" To: Tom Yu Cc: "Barry Jaspan" , 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 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 To: "Barry Jaspan" 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 >>>>> "Barry" == "Barry Jaspan" writes: Barry> Furthermore, if it is so easy to change smoothly, then we can Barry> change it in the future. 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 To: "Theodore Y. Ts'o" Cc: Tom Yu , "Barry Jaspan" , 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 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 > 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? 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 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" 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 >> * Menu: >> >> * Introduction:: >> * Realm Configuration Decisions:: >> * Building Kerberos V5:: >> * Installing Kerberos V5:: >> * Upgrading existing Kerberos V5 installations:: >> * Bug Reports for Kerberos V5:: >> * Files:: 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. >Unformatted: