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

 
 

bug #31436: move process into a screen session

Submitted by:  None
Submitted on:  Sun 24 Oct 2010 09:27:20 PM UTC  
 
Category: Feature RequestSeverity: 3 - Normal
Priority: 5 - NormalStatus: Wont Fix
Privacy: PublicAssigned to: None
Open/Closed: ClosedRelease: None
Fixed Release: NonePlanned Release: None
Work Required: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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 File(s):
   
   
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
  • -unavailable- added by amade (Posted a comment)
  • -unavailable- added by nicm (Posted a comment)
  • -unavailable- added by jnweiger (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 09 Jul 2017 10:18:06 PM UTCamadeStatusNone=>Wont Fix
      Open/ClosedOpen=>Closed
    Sun 24 Oct 2010 09:27:20 PM UTCNoneAttached File-=>Added sm.c, #21797

    Back to the top


    Powered by Savane 3.1-cleanup1