Re: strange limitation on rcmd()

俵恓藻昑쬠10 旻陓挎 2006 13:50, Brian Candler 恔倅蚆휺
> Well, it's probably worth send-pr'ing it.

The rcmdsh() is taken from OpenBSD, I think, and has no room for the stderr. 
One would need to reimplement something like rcmdsh2() first :-)

> I'd first test whether rsh itself forwards stderr properly. Maybe there's
> some underlying reason why rcmdsh doesn't have an fd2p argument.

     The rsh utility copies its standard input to the remote command, the
     standard output of the remote command to its standard output, and the
     standard error of the remote command to its standard error.

ssh seems compliant too. The signal-handling is different, though:

     Interrupt, quit and terminate signals are propagated to the remote
     command;

Whereas with rcmd one just writes the signal number (any signal number) into 
the fd2 descriptor...

I think, rcmd() should just try to connect and leave it to the remote to 
reject it based on the too-low port number or anything.

Another approach would be to use a separate suid utility (Linux has rcmd(1), 
for example), with semantics more closely matching those of rcmd(3).

The reason I like rcmd() is that it lets me send data to a remote machine a) 
_directly_ from my program; and b) without also implementing the server side.

I could achieve both of these with a non-root process by disabling 
the "isroot" checks inside the rcmd and by configuring the server to accept 
rcmd from any port. Other approaches require the root's setuid bit on the 
program, or abandoning the _directness_ of the a) by copying many gigabytes 
through the client's memory buffers a couple of extra times.

	-mi
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"