<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Szabolcs,<div class=""><br class=""></div><div class="">Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon as the user, while Dropbear runs as root.</div><div class=""><br class=""></div><div class="">The procfs manpage mentions the problem. <a href="http://man7.org/linux/man-pages/man5/proc.5.html" class="">http://man7.org/linux/man-pages/man5/proc.5.html</a></div><div class=""><pre style="margin-left: 8px; caret-color: rgb(24, 24, 24); color: rgb(24, 24, 24); background-color: rgb(255, 255, 255);" class=""><font face="Courier New" class=""> Note that for file descriptors referring to inodes (pipes and
sockets, see above), those inodes still have permission bits
and ownership information distinct from those of the
<i style="color: rgb(0, 96, 0);" class="">/proc/[pid]/fd</i> entry, and that the owner may differ from the
user and group IDs of the process. An unprivileged process
may lack permissions to open them, as in this example:
$ <b style="color: rgb(80, 32, 0);" class="">echo test | sudo -u nobody cat</b>
test
$ <b style="color: rgb(80, 32, 0);" class="">echo test | sudo -u nobody cat /proc/self/fd/0</b>
cat: /proc/self/fd/0: Permission denied</font></pre><div class="">Not really sure of a good workaround.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Matt</div><div class=""><br class=""></div><div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Fri 1/5/2020, at 2:46 am, Szabolcs Nagy <<a href="mailto:nsz@port70.net" class="">nsz@port70.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">hello, when dropbear server runs on host<br class=""><br class="">$ echo hi | ssh user@host 'cat'<br class=""><br class="">works as expected (so reading stdin works), but<br class=""><br class="">$ echo hi | ssh user@host 'cat /proc/self/fd/0'<br class=""><br class="">fails with EPERM (the open syscall in cat that is).<br class=""><br class="">it seems the /proc file is user owned but it's a magic symlink<br class="">to a pipe that is owned by root so reopening it fails:<br class=""><br class="">$ ssh user@host 'stat -L /proc/self/fd/0'<br class=""> File: /proc/self/fd/0<br class=""> Size: 0 Blocks: 0 IO Block: 4096 fifo<br class="">Device: bh/11d Inode: 7193 Links: 1<br class="">Access: (0600/prw-------) Uid: ( 0/ root) Gid: ( 0/ root)<br class="">Access: 2020-04-30 18:29:01.000000000<br class="">Modify: 2020-04-30 18:29:01.000000000<br class="">Change: 2020-04-30 18:29:01.000000000<br class=""><br class="">i haven't seen this behaviour with openssh and affects some<br class="">scripts that use /dev/stdin, /dev/stdout, /dev/stderr<br class="">(which just point to /proc/self/fd/{1,2,3})<br class=""><br class="">if there is a simple workaround i'd like to hear about it.<br class="">thanks<br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>