>Now, the above eventually resolves to the following, where everything
>bar the rcmd is executed as superuser, courtesy of setuid "backend":

>	find {something} | cpio -i {opts} | rcmd remote cpio -o {opts}

run fstat -p against the cpio -o process and its parent etc.
You may find someone has an open descriptor that is preventing
cpio from seeing EOF.

Not really sure if its relevant, but unlike traditional rcmd(3),
rmcd(1) which actually does the deed for it in 1.5.x always opens
a 2nd channel for stderr.  Unfortunately the design provides no way for
rcmd(3) to communicate to rcmd (or more importantly to rsh,ssh etc)
that no 2nd channel is wanted and you may be ending up with the 
input socket being duped.

This bug bites in other ways (like trying to pass through a proxy), 
and I came up with a hack - that works for rsh at least, 
but there's really no real way to fix it since the point
of rcmd(1) is to be able to replace the transport (rsh by default) with
say ssh so you can't rely on adding an option or anything else really
and not break that goal.

Anyway I never committed the hack and never came up with a real solution.
Look at the fstat -p output, and see the addresses that represent the
end-points of cpio's stdin.  The only other process in which you should
see those end-points is the one feeding data to cpio.  Any other process
or a process with more than one copy, suggests you have an FD leak
and cpio will never see EOF.

Hope that helps
--sjg