Posts: 116
Threads: 3
Joined: Sep 2014
Thanks: 31
Given 15 thank(s) in 11 post(s)
12-21-2015, 10:50 PM
(This post was last modified: 12-21-2015, 10:54 PM by jan64.)
"Massive security hole v0.1" ?
You could try redirecting the output using "./malware > out.txt < in.txt 2>&1", which should work both in linux and windows.
Although, i have no idea why it would deadlock except for the command not terminating.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Actually it's a problem with how Linux handles creating new processes. It does so by using fork(), which duplicates the current process, and then exec(), which replaces the current binary with another binary. It works pretty well for traditional programs, but doesn't cooperate too well with threads - only the thread calling the fork() function is copied, the rest of the threads are thrown away in the copy of the executable, which means that if any of those threads held any mutexes, those mutexes will be locked forever in the child process. If one of those mutexes just happens to be something important, such as CRT's mutex for memory allocations, we're in trouble.
Posts: 36
Threads: 7
Joined: Jun 2015
Thanks: 18
Given 1 thank(s) in 1 post(s)
Is there any other way to communicate with the OS? I believe creating a file is enough. After a server restart the server script can detect the file and react (Plan B).
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Creating a file should be easy enough - use Lua's built-in IO library.
Another option would be to use an external process listening on a socket to actually execute the commands. You'd lose the possibility of IO redirection and waiting for process end, but it would work. Also, not too platform-independent.