[3148] in Kerberos-V5-bugs
krb5-libs/785: srvtab resolution
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Thu Nov 4 16:46:39 1999
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, ghudson@MIT.EDU
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
>Number: 785
>Category: krb5-libs
>Synopsis: srvtab resolution function is different from file one
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Nov 04 16:46:03 EST 1999
>Last-Modified:
>Originator: Greg Hudson
>Organization:
MIT
>Release: krb5-1.0.6
>Environment:
System: SunOS small-gods.mit.edu 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4
>Description:
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.
>How-To-Repeat:
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.
>Fix:
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 ----
>Audit-Trail:
>Unformatted:
