Hi Szabolcs, Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon as the user, while Dropbear runs as root.
The procfs manpage mentions the problem. http://man7.org/linux/man-pages/man5/proc.5.html 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 /proc/[pid]/fd 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: $ echo test | sudo -u nobody cat test $ echo test | sudo -u nobody cat /proc/self/fd/0 cat: /proc/self/fd/0: Permission denied Not really sure of a good workaround. Cheers, Matt > On Fri 1/5/2020, at 2:46 am, Szabolcs Nagy <n...@port70.net> wrote: > > hello, when dropbear server runs on host > > $ echo hi | ssh user@host 'cat' > > works as expected (so reading stdin works), but > > $ echo hi | ssh user@host 'cat /proc/self/fd/0' > > fails with EPERM (the open syscall in cat that is). > > it seems the /proc file is user owned but it's a magic symlink > to a pipe that is owned by root so reopening it fails: > > $ ssh user@host 'stat -L /proc/self/fd/0' > File: /proc/self/fd/0 > Size: 0 Blocks: 0 IO Block: 4096 fifo > Device: bh/11d Inode: 7193 Links: 1 > Access: (0600/prw-------) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2020-04-30 18:29:01.000000000 > Modify: 2020-04-30 18:29:01.000000000 > Change: 2020-04-30 18:29:01.000000000 > > i haven't seen this behaviour with openssh and affects some > scripts that use /dev/stdin, /dev/stdout, /dev/stderr > (which just point to /proc/self/fd/{1,2,3}) > > if there is a simple workaround i'd like to hear about it. > thanks
