l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2011 Oct 27 19:45

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] writing to a shell instance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] writing to a shell instance

On Wed, Oct 26, 2011 at 10:39 PM, Ken Bloom <kbloom@gmail.com> wrote:
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.

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).

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 brand new slave. 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.)

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 were 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.

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 http://ingvar.blog.redpill-linpro.com/2010/07/10/changing-a-process-file-descriptor-on-the-fly/

It's possible to transfer a file descriptor between processes using a unix domain socket (see http://stackoverflow.com/questions/2358684/can-i-share-a-file-descriptor-to-another-process-on-linux-or-are-they-local-to-t/2358843#2358843) 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.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!