Re: krb5 port: -current behaves differently than 4.X w.r.t rsh

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_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)
> _______________________________________________
> 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"
>