bugGNU Screen - Bugs: bug #31436, move process into a screen session

 
 

bug #31436: move process into a screen session

Submitter:  None
Submitted:  Sun 24 Oct 2010 09:27:20 PM UTC
   
 
Category:  Feature Request Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  None
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 09 Jul 2017 10:18:06 PM UTC, comment #4: 

One can use such tools as reptyr to do this, I don't think it should be in scope of screen to move external processes inside.

Amadeusz Sławiński <amade>
Group administrator
Wed 27 Oct 2010 10:44:53 PM UTC, comment #3: 

I've thought this would be a nice thing to do but your solution (although clever and kind of funky) is completely unportable both across platforms and architectures.

There is a program called neercs that does a similar thing by using ptrace to permanently hook various syscalls, but again that is a hack that is completely unportable to anything beyond Linux/x86.

My thought was that a kernel API is needed to transfer ownership of the master side of a pty (move it to an fd in another process). Obviously this wouldn't work for the console but it would allow processes to be moved between pty users (such as xterm), although it would require modification at least of the receiving process.

Nicholas Marriott <nicm>
Tue 26 Oct 2010 04:52:17 PM UTC, comment #2: 

I'm using the line numbers as given in the blog. The asm code does this:
15: that's just a marker for me to be able to find the function later more easy
16: decrease the stack pointer to put a struct sigaction in there
17: put SIG_IGN in there - SIG_IGN is just the number 1
18: first argument for the rt_sigaction syscall is on which signal you want to operate; we want to ignore signal SIGHUP - SIGHUP has the value 1
19: second argument for the rt_sigaction syscall is the pointer to the sigaction struct
20: in case you want to store the old signal behaviour you could set the third argument to non-NULL; we don't do this here and set it to null
21: the fourth argument is size_t sigsetsize; that's 8
22: so, as specified in /usr/include/asm/unistd_64.h the syscall number for rt_sigaction is 13; so we just put that into rax
23: syscall: just execute the syscall

that's how easy it is to ignore a signal ;)

24: now, we want to open a file; the syscall number for open is 2
25: move "\0l" into rbx
26: push that on the stack
27: move "/dev/nul" into rbx
28: push that on the stack
29: first argument for open is which file you want to open; filename is stored on the stack at rsp
30: we open the file in mode O_WRONLY; thats a symbol for 1
31: execute that syscall

that's how easy it is to open the file /dev/null in mode O_WRONLY
I put "/dev/null\0" on the stack, because it would be to complicated to put it into the data segment and adjust the address correctly.

32: the open syscall returned in eax the filedescriptor number; we want to use that number as second argument for dup2; so we put it into rdi
33: first argument of dup2 is which filedescriptor should be moved; that's stdout (number 1)
34: syscall number for dup2 is 33 or 0x21
35: execute the syscall

that's how easy it is to move the stdout to /dev/null

37: 0x2 is the syscall for the open syscall
38: we want to open the file "/dev/null\0"
39: second argument for open is how we want to open that file; we want to open it O_RDONLY (=0)
40: just syscall

now we have opened "/dev/null\0" twice; first WRONLY, second RDONLY

41: same as in line 32
42: we want to move stdin (=0)
43: same as in line 34
44: syscall

now we have connected stdin to RDONLY opened /dev/null
lines 45 and following do the same for stderr and WRONLY /dev/null


No, I don't think it could be written in C.
To make that portable I have only ideas:
- write a loader (in asm) -> loader is not portable
- parse the glibc, klibc and find the right opcodes :(
- perhaps it's possible to write llvm-asm and get out opcodes for several architectures

I should add, that this is only a proof of concept what is possible!
Perhaps it would be easier to code this in kernel-mode; but I'm not a kernel hacker :(

If you have more questions, don't hesitate to ask me.

Anonymous
Mon 25 Oct 2010 09:45:38 PM UTC, comment #1: 

Please add a detailled description what the assembler code does.
Could this also be written in C? We need our code to be very portable.

Juergen Weigert <jnweiger>
Group administrator
Sun 24 Oct 2010 09:27:20 PM UTC, original submission:  

Hi
wouldn't it be cool to move a running programm (i.e. a process) into a screen session.
I made a proof of concept:
http://www.spin.de/hp/btwotch/blog/id/10448848


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #21797:  sm.c added by None (5KiB - text/x-csrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by nicm (Posted a comment)
  • -email is unavailable- added by jnweiger (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-09 amade StatusNone Wont Fix
        Open/ClosedOpen Closed
    2010-10-24 None Attached File- Added sm.c, #21797

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code