From owner-freebsd-ports-bugs@FreeBSD.ORG Wed Mar 2 19:50:03 2005 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115CD16A4CE for ; Wed, 2 Mar 2005 19:50:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F74943D41 for ; Wed, 2 Mar 2005 19:50:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j22Jo2R0012128 for ; Wed, 2 Mar 2005 19:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j22Jo2G2012127; Wed, 2 Mar 2005 19:50:02 GMT (envelope-from gnats) Resent-Date: Wed, 2 Mar 2005 19:50:02 GMT Resent-Message-Id: <200503021950.j22Jo2G2012127@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Tillman Hodgson" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F39DE16A4CE for ; Wed, 2 Mar 2005 19:46:52 +0000 (GMT) Received: from mail.seekingfire.com (caliban.rospa.ca [24.72.10.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5132243D31 for ; Wed, 2 Mar 2005 19:46:52 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: from backforty.seekingfire.prv (backforty.seekingfire.prv [192.168.23.42]) by mail.seekingfire.com (Postfix) with ESMTP id 85291437 for ; Wed, 2 Mar 2005 13:46:51 -0600 (CST) Message-Id: <1109792811.0@backforty.seekingfire.prv> Date: Wed, 2 Mar 2005 13:46:51 -0600 From: "Tillman Hodgson" To: "FreeBSD gnats submit" X-Send-Pr-Version: gtk-send-pr 0.4.4 Subject: ports/78325: -current behaves differently than 4.X w.r.t rsh from security/krb5 port X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 19:50:03 -0000 >Number: 78325 >Category: ports >Synopsis: -current behaves differently than 4.X w.r.t rsh from security/krb5 port >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 02 19:50:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Tillman Hodgson >Release: FreeBSD 6.0-CURRENT i386 >Organization: >Environment: System 1: FreeBSD 6.0-CURRENT #0: Mon Jan 24 09:41:28 CST 2005 tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY System 2: FreeBSD 6.0-CURRENT #0: Tue Mar 1 16:04:05 CST 2005 toor@thoth.seekingfire.com:/usr/obj/usr/src/sys/THOTH i386 System 3: FreeBSD 4.10-STABLE #0: Thu Nov 18 12:49:31 CST 2004 toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/ATHENA i386 >Description: Note: I originally posted this problem to freebsd-ports@ on Nov 23 2004, with a followup to current@ on Dec 14 2004. The problem still exists in -current with src from as recent as March 01 2005 so I figured I'd file a PR so that the issue can be properly tracked. I run a couple of Kerberos realms. in late 2004 I installed some new 5.3R machines and then immediately upgraded them to -current. Cursory testing seemed to show that the MIT Kerberos port (security/krb5) was working correctly. Over time, I've found a regression between it and my older 4.X systems (of which I have only remaining). While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic Kerberos-enabled tools work correctly, the kerberos rsh client (not the server, it's fine) doesn't work on -current. Here's a a 4-stable box connecting via rsh to another 4-stable box as well as to a -current box: [root@athena ~]# rsh -x coyote uname -a This rsh session is encrypting input/output data transmissions. FreeBSD coyote.seekingfire.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Thu Nov 18 13:10:32 CST 2004 toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE i386 [root@athena ~]# rsh -x backforty uname -a This rsh session is encrypting input/output data transmissions. FreeBSD backforty.seekingfire.prv 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Nov 19 08:03:52 CST 2004 tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY i386 When I try to connect from the -current box ('backforty' from the example above) outwards to either type of box I get a failure: $ rsh -x coyote uptime socket: protocol error or closed connection in circuit setup $ rsh -x caliban uptime socket: protocol error or closed connection in circuit setup (caliban is another -current box, in thsi case a sparc64 one). The auth.log on the server-side system shows: Nov 23 15:55:10 athena kshd[4565]: connect second port: Connection refused Note that all other client Kerberos apps work: I can telnet -x, ftp -x, rlogin, etc to my hearts connect. Only rsh displays this behaviour. I've confirmed that I'm running the right rsh binary: $ which rsh /usr/local/krb5/bin/rsh And I've confirmed that they're both running up-to-date ports trees and the most current version fo security/krb5. I've confirmed that inetd.conf is set up identically between the 4.X and the -current sysetms for the kshd line. I've googled for the auth.log message. It seems that the connection "back" for stderr is being denied. By what, I don't know ... the host backforty isn't running any sort of firewall: root@backforty# ipfw list ipfw: getsockopt(IP_FW_GET): Protocol not available root@backforty# ipfstat -hin open: No such file or directory root@backforty# pfctl -s rules pfctl: /dev/pf: No such file or directory I've confirmed that this issue exists for every -current box that I've run across (I run 4 myself). The problem is particularly vexing because Kerberos rsh is commonly used for securing "cluster" type operations (rmt for remote central backups, the clusterit port, central management scripting, etc). >How-To-Repeat: Install security/krb5 port (the MIT Kerberos port) on a -current system. Try to use the rsh client that it installs. Compare with the results on a 4.X system. I have a good working knowledge of Kerberos and I'm willing to do testing across a variety of systems if someone wants to test a potential fix :-) >Fix: >Release-Note: >Audit-Trail: >Unformatted: