krb5 port: -current behaves differently than 4.X w.r.t rsh
Cy Schubert
Cy.Schubert at komquats.com
Thu Dec 2 13:52:29 PST 2004
Under 5.3 & 6.0 bind in kcmd returns EPERM. In my case there is no firewall
involved as the hosts are all on the same network. I believe that this is
some sort of kernel issue when a wildcard IP:port is passed to bind(2).
Cheers,
Cy Schubert <Cy.Schubert at komquats.com>
Web: http://www.komquats.com and http://www.bcbodybuilder.com
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
BC Government: <Cy.Schubert at gems8.gov.bc.ca>
"Lift long enough and I believe arrogance is replaced by
humility and fear by courage and selfishness by generosity
and rudeness by compassion and caring."
-- Dave Draper
In message <20041123220009.GJ88293 at seekingfire.com>, Tillman Hodgson writes:
> 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 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)
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>
More information about the freebsd-ports
mailing list