krb5 port: -current behaves differently than 4.X w.r.t rsh (possibly EPERM from bind)

From: Tillman Hodgson <tillman_at_seekingfire.com>
Date: Tue, 14 Dec 2004 10:51:44 -0600
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 - )

attached mail follows:


Howdy folks,

[I'm not sure that ports_at_ 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_at_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_at_athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE  i386

[root_at_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_at_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_at_backforty# ipfw list
ipfw: getsockopt(IP_FW_GET): Protocol not available
root_at_backforty# ipfstat -hin
open: No such file or directory
root_at_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)
Received on Tue Dec 14 2004 - 15:51:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:24 UTC