防止POSIX系统上的文件描述符关闭

Question

There is a library (libvte, a terminal emulation library) that uses a pair of file descriptors for a pty master/slave pair. I need to be able to "steal" the master fd from the library for my own use (in order to implement support for ZMODEM for the very rare occasion when the only link I have to the 'net is via a terminal). However, there is a problem.

You can tell libvte that you want to change the file descriptor to a new one, but then it attempts to close the master that it is using, and start using the new one instead. This won't work, because when the master is closed the slave goes away. Originally, I thought that it would be possible to use dup() on the pty master, such that when libvte did close() on the PTY master, I'd still have a functioning fd to use. That is apparently wrong.

I need to find a way to either:

• Block libvte's read() operations on the fd.
• Steal the fd away from libvte until I'm doing using it (eg, until the rz process that I am connecting it to exits)

Is it possible on a POSIX system to do either of these things? Or would there be some other way to accomplish the same thing without patching libvte itself? The reason that I ask is that the solution has to work on a fair number of existing systems.

If it is at all relevant, I'm interfacing with libvte (and GTK+ itself) via Python. However, I'd not be averse to writing a Python extension in C that I could then call from a Python program, because you don't have to be privileged on any system to load a Python extension.

If none of it is possible, I may be forced to fork libvte to do what I want it to do and distribute that with my program, but I don't want to do that --- I do not want to be stuck maintaining a fork!

Answer 1

One possible solution would be to write a helper process which opens its own pty master/slave pair, and interposes between libvte and the actual target program that runs on the slave pty:

+---------------+
| libvte        |
|               |
|    pty master=|-----\
+---------------+     |
                      |
+---------------+     |
| helper proxy  |     |
|               |     |
|  stdin/stdout=|-----/
|               |
|    pty master=|-----\
+---------------+     |
                      |
+---------------+     |
| target        |     |
|               |     |
|  stdin/stdout=|-----/
+---------------+

Your helper process normally just passes through data, until it sees ZMODEM traffic. It then stops passing data to stdin / stdout (which winds up at libvte ) and instead either passes it to your application through a separate file descriptor, or even just invokes rz itself.

Answer 2

dup() 'd file descriptors are not affected by close() calls of other instances; however, it's possible libvte may be calling some other shutdown methods which do change its state. Use strace to investigate in more detail.

Apart from that, there are a few things you can do, but none of them are very pretty. One option would be to replace the file descriptor from under libvte. That is:

• First, use dup() to get your own copy of the fd, and stash it somewhere
• Use dup2() to overwrite libvte's fd with one of your own choosing. This should be a new pty with a configuration similar to that of the one you're stealing, to avoid confusing libvte. Since you'll never write anything to the other end, reads will block (you'll need to do something with any data libvte may write down there!)
• If libvte may be in a blocking read() at that very moment, send a signal to its thread (with a no-op - not SIGIGN - handler) to interrupt the read() call.
• Do your work with the fd you duplicated at the start
• To return to normal, use dup2() to put the fd back, then copy any pty state changes libvte may have made to the original descriptor.

Alternately, you can do as caf suggests, and simply have a proxy pty in there from the start.