Ticket History #785: srvtab resolution function is different from file one

From kerberos-acl@MIT.EDU Thu Nov 4 16:45:04 1999
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA06295 for <bugs@RT-11.MIT.EDU>; Thu, 4 Nov 1999 16:45:04 -0500
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
id AA26124; Thu, 4 Nov 99 16:45:25 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id QAA08718
for <krb5-bugs@MIT.EDU>; Thu, 4 Nov 1999 16:45:02 -0500 (EST)
Received: from small-gods.mit.edu (SMALL-GODS.MIT.EDU [18.177.0.248])
by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id QAA08135
for <krb5-bugs@mit.edu>; Thu, 4 Nov 1999 16:45:02 -0500 (EST)
Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3)
id QAA07959; Thu, 4 Nov 1999 16:45:01 -0500 (EST)
Message-Id: <199911042145.QAA07959@small-gods.mit.edu>
Date: Thu, 4 Nov 1999 16:45:01 -0500 (EST)
From: ghudson@MIT.EDU
Reply-To: ghudson@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: srvtab resolution
X-Send-Pr-Version: 3.99

MIT

System: SunOS small-gods.mit.edu 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4

A few years ago, I submitted code implementing the SRVTAB and ANY keytab
types. The SRVTAB type could read v4 srvtab files and the ANY type would
try to resolve a list of keytabs until it found one which worked.
Together these keytab types allowed a smooth transition from srvtabs to
keytabs on server machines. As part of the ANY keytab type, I had
proposed a change to the interface such that the resolve operation would
fail with ENOENT if the underlying file does not exist.

The krb5 team accepted my SRVTAB code and rejected my ANY code, as well
as the modification to the resolve function of the FILE code. (And
they didn't seem to bother telling me what their decision was, but
perhaps I merely forgot.) However, they did not remove the part of my
SRVTAB code which implemented the change in the resolve interface. So
now the FILE resolve function will succeed even if the keytab is not
present, but the SRVTAB resolve function will fail if there is no
srvtab.
Set the default keytab to SRVTAB:filename and try to log in when the
srvtab doesn't exist. Since krb5_verify_init_creds() assumes the
traditional semantics of the resolve interface (no such thing as an
ENOENT from the resolve function), you won't be able to log in.
I (mostly) have a new implementation of the ANY keytab type which
doesn't change the resolve interface, incidentally. It's naturally
a lot more code since it has to implement its own operations, but if
the interface change was the reason for rejecting ANY, please let me
know and I'll submit the new version.

Index: kts_resolv.c
===================================================================
RCS file: /afs/dev.mit.edu/source/repository/third/krb5/src/lib/krb5/keytab/srvtab/kts_resolv.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 kts_resolv.c
*** kts_resolv.c 1999/10/05 16:14:37 1.1.1.1
--- kts_resolv.c 1999/11/04 21:42:20
***************
*** 38,50 ****
krb5_keytab *id;
{
krb5_ktsrvtab_data *data;
- FILE *fp;
-
- /* Make sure we can open the srvtab file for reading. */
- fp = fopen(name, "r");
- if (!fp)
- return(errno);
- fclose(fp);

if ((*id = (krb5_keytab) malloc(sizeof(**id))) == NULL)
return(ENOMEM);
--- 38,43 ----