Date: Tue, 14 Dec 2004 10:51:44 -0600 From: Tillman Hodgson <tillman@seekingfire.com> To: FreeBSD -CURRENT <current@freebsd.org> Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh (possibly EPERM from bind) Message-ID: <20041214165144.GJ17907@seekingfire.com>
next in thread | raw e-mail | index | archive | help
--NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Howdy folks, I'm this on trying on -current to see if I can work with someone here to get this problem trouble-shot and fixed. There was a brief follow-up on the ports mailing list (viewable at http://groups.google.ca/groups?hl=en&lr=&selm=1102037006.00184340.1102024801%4010.7.7.3) describing how 5.3 and 6.0 bind in kcmd returns EPERM in spite of there being no firewall in place. -T -- "Humanity has advanced, when it has advanced, not because it has been sober, responsible, and cautious, but because it has been playful, rebellious, and immature." -- Tom Robbins (1936 - ) --NzB8fVQJ5HfG6fxh Content-Type: message/rfc822 Content-Disposition: inline Date: Tue, 23 Nov 2004 16:00:09 -0600 From: Tillman Hodgson <tillman@seekingfire.com> To: FreeBSD-Ports <freebsd-ports@freebsd.org> Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh Message-ID: <20041123220009.GJ88293@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>. X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.6i Howdy folks, [I'm not sure that ports@ is the right place for this, but thought I'd start here and see what happens.] I run a couple of Kerberos realms. I recently installed some new 5.3R machines and then immediately upgraded them to -current. Cursory testing (I know, I know) seemed to show that the MIT Kerberos port (security/krb5) was working correctly. Over time, I've found a difference between it and my older 4.X systems. While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic tools work correctly, the kerberos rsh client (not the server, it's fine) doesn't seem to work. Here's a a 4-stable box connecting via rsh to anotehr 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). 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 otehr 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 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 runnign 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 Any ideas? -T -- >I've gone through over-stressed to physical exhaustion... what's next? Tuesday - A.S.R. quote (Simon Burr & Kyle Hearn) --NzB8fVQJ5HfG6fxh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214165144.GJ17907>