<br><br><div class="gmail_quote">On Wed, Oct 26, 2011 at 10:39 PM, Ken Bloom <span dir="ltr"><<a href="mailto:kbloom@gmail.com">kbloom@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>You would think that you could write to /dev/$PID/fd/0 and have that be the input into bash, but you can't. ttys are wierd.</div><div><br></div>Xterm uses the Unix 98 pseudo terminal interface to talk to its child process using a /dev/pts/something device file. It calls open("/dev/ptmx") which is the single Unix 98 pesudo-terminal device in the system, and which behaves somewhat wierd. Every time you open /dev/ptmx, it creates a new /dev/pts slave device. After making several system calls on the /dev/ptmx device, it calls ptsname on the file descriptor it has for /dev/ptmx, and gets (as a string) the name of the /dev/pts slave device. The process can give this name to whomever it pleases, either by sending the client the string somehow, or by opening the /dev/pts device and letting the child process inherit the file descriptor of the slave device (just like you do when setting up input redirection using pipes).<div>
<br></div><div>Basically, if you want to write something to the tty, so that the child process (bash, in your case) can read it, you have to write to the master device /dev/ptmx. But you can't just open /dev/ptmx and be routed to the right slave, because if you call open(/dev/ptmx), you get a <i>brand new slave</i>. So if you want to send data to the same /dev/pts slave that the Xterm is sending data to, you need to get the file descriptor from the Xterm, which AFAIK has to be done by inheriting it as a child process. (Even using /proc/PID/fd won't help because the file descriptor shows up there as a symlink to the slave device.)</div>
<div><br></div><div>When you tried to hijack /dev/pts/13 to write the ls command to bash, you were writing to the slave device. This data is read back from the master fd in the Xterm. The ls command was sent directly to the Xterm, and bash never saw it at all. So what happened was that you acted like you <i>were</i> the bash shell, not like you were the Xterm, and no technique for writing a newline would help you get your ls command interpreted by bash.</div>
<div><br></div><div><br></div><div>Since you wanted send a command to bash, you could either use a pipe, or you could use gdb to hijack bash's stdin, as described at <a href="http://ingvar.blog.redpill-linpro.com/2010/07/10/changing-a-process-file-descriptor-on-the-fly/" target="_blank">http://ingvar.blog.redpill-linpro.com/2010/07/10/changing-a-process-file-descriptor-on-the-fly/</a>. </div>
</blockquote><div><br></div><div><br></div><div>It's possible to transfer a file descriptor between processes using a unix domain socket (see <a href="http://stackoverflow.com/questions/2358684/can-i-share-a-file-descriptor-to-another-process-on-linux-or-are-they-local-to-t/2358843#2358843">http://stackoverflow.com/questions/2358684/can-i-share-a-file-descriptor-to-another-process-on-linux-or-are-they-local-to-t/2358843#2358843</a>) so it's possible for the Xterm to share its file descriptor for the /dev/ptmx master with another process. Whether you can use this method to hijack the file descriptor with GDB is anybody's guess. If you come up with a devious way to do that, please share.</div>
<div><br></div></div>