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: 3945 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 ; 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 ; 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 ; 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 >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: