I've been thinking about building a way to move a job between shells, in particular between one window, ssh session, whatever, and another.
Obviously, this will involve much hackery of existing facilities. For example, it involves switching controlling terminals. I expect I can manage most of it without too much trouble - though that's said without having actually tried it. But the real bugaboo in my mind is reparenting processes. I'm writing here to ask two questions. One is: does anyone have experience trying this, or otherwise have any reports on attempts to do this, to share? I'd be interested in any. The other is: is there any security property that such a facility would break badly? (There are lots of minor things that might break, such as potentially changing terminal type, but that's basically no different from telling the terminal emulator to change emulation on the fly, which my terminal emulator has been capable of for decades. I haven't come up with any major security issues yet, but that means little.) I'm willing to require - indeed, I expect to _want_ to require - that the two parents (old and new) be cooperating in this endeavour. I'm willing to require that all three processes be running with the same root, though it'd be nice if that weren't necessary. It would address some, though not all, of the desired use cases if all three processes have to be running with the same UID. It would even be of _some_ use if it required cooperation from root in some form (a fourth process, maybe?). As far as I can tell, reparenting currently is limited to (1) init inheriting orphans and (2) sharply limited partial reparenting due to ptrace(). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B