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: 3916 From donn@u.washington.edu Wed Apr 22 12:42:20 1998 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 MAA26231 for ; Wed, 22 Apr 1998 12:42:19 -0400 Received: from melville.u.washington.edu by MIT.EDU with SMTP id AA10576; Wed, 22 Apr 98 12:42:12 EDT Received: (from donn@localhost) by melville.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) id JAA105042; Wed, 22 Apr 1998 09:42:07 -0700 Message-Id: <199804221642.JAA105042@melville.u.washington.edu> Date: Wed, 22 Apr 1998 09:42:07 -0700 From: donn@u.washington.edu Reply-To: donn@u.washington.edu To: krb5-bugs@MIT.EDU Subject: gssftp ftp host lookup X-Send-Pr-Version: 3.99 >Number: 583 >Category: krb5-appl >Synopsis: ftp fails to look up actual host domain name >Confidential: no >Severity: serious >Priority: medium >Responsible: krb5-unassigned >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Wed Apr 22 12:43:01 EDT 1998 >Last-Modified: >Originator: Donn Cave >Organization: University of Washington >Release: 1.0.5 >Environment: All System: AIX melville 2 4 00600210C000 >Description: The gssftp ftp client doesn't look up the domain name for its connection - i.e., "reverse" lookup using gethostbyaddr(). This means that lookup is deferred to gss_import_name() (where the lookup is courtesy of krb5_sname_to_principal()). This deferred lookup is not reliable, in cases where the original domain name given to the client is a DNS random cluster of some kind and the resolution from cluster to specific host is naturally variable. Hence, the ftp client must look up the actual host from its IP connection. >How-To-Repeat: Attempt to connect via ftp to dante.u.washington.edu, or any cluster that resolves to specific host on a variable schedule. It's important to get this fixed in the distribution, because large cluster sites like ours can fix the problem only for internal connections, outside we're limited to distributing a patch or something. >Fix: *** krb5-1.0.4/src/appl/gssftp/ftp/ftp.c Thu Dec 4 19:41:58 1997 --- krb5-1.0.5/src/appl/gssftp/ftp/ftp.c Wed Apr 22 09:04:54 1998 *************** *** 1841,1846 **** --- 1841,1848 ---- #if defined(KERBEROS) || defined(GSSAPI) u_char out_buf[FTP_BUFSIZ]; int i; + char realhostname[128]; + struct hostent *hp; #endif /* KERBEROS */ if (auth_type) return(1); /* auth already succeeded */ *************** *** 1923,1928 **** --- 1925,1944 ---- chan.application_data.length = 0; chan.application_data.value = 0; + /* + ** Look up actual host name, from connection IP. + ** Since gss_import_name() -> krb5_sname_to_principal() + ** will arrive at an actual name anyway, this is not a + ** question of whether we want the cluster name or the + ** actual name, but whether we want the actual name to + ** be the correct one. + */ + hp = gethostbyaddr(&hisctladdr.sin_addr, 4, AF_INET); + if (hp) + strcpy(realhostname, hp->h_name); + else + strcpy(realhostname, hostname); + for (end_service_name = gss_services; *end_service_name; ) end_service_name++; end_service_name--; *************** *** 1937,1943 **** /* ftp@hostname first, the host@hostname */ /* the V5 GSSAPI binding canonicalizes this for us... */ ! sprintf(stbuf, "%s@%s", *service_name, hostname); if (debug) fprintf(stderr, "Trying to authenticate to <%s>\n", stbuf); --- 1953,1959 ---- /* ftp@hostname first, the host@hostname */ /* the V5 GSSAPI binding canonicalizes this for us... */ ! sprintf(stbuf, "%s@%s", *service_name, realhostname); if (debug) fprintf(stderr, "Trying to authenticate to <%s>\n", stbuf); >Audit-Trail: >Unformatted: