|
Home > Archive > Unix Programming > July 2007 > How to use fork-exec system call to redirect stdout/stderr to a buffer?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to use fork-exec system call to redirect stdout/stderr to a buffer?
|
|
| Jaw109 2007-07-10, 1:23 pm |
| Hi there
I am a beginner for system programming, I'd like to use fork-exec
programming to perform a "C-code compilation" and see if any
compilation errors within ......
**
For now, I had create a process to perform the system call *exec()*. I
could make the main process to wait the created one, like this...
[CODE]
pid_t pid = fork();
if(isErrorProc(pid))
{
printf("This message means it failed to create a process\n");
exit(1);
}
if(isMainProc(pid))
{
wait( (int*)0 ); // wait for created process has been finished.
/* Do something herefor stdout/stderr generated by child process*/
exit(0);
}
if(isChildProc(pid))
{
execl("/bin/ls", "ls", "-la", ">", "log.txt", (char*)0);
printf("This message means system call *execl()* failed\n");
exit(1);
}
[/CODE]
Okay,
For my observation, *execl()* pass the command ">" to "ls" as a
parameter. The program "ls" treat ">" as a target file name or
something.
So I think ">" is a shell command(or operator something), right?
then how should I redirect a stdout/stderr to a buffer(or a file)?
| |
| David Schwartz 2007-07-10, 1:23 pm |
| On Jul 10, 6:53 am, Jaw109 <jaw...@gmail.com> wrote:
> then how should I redirect a stdout/stderr to a buffer(or a file)?
In-between the 'fork' and the 'exec', you can change the file
descriptors around however you want. The 'dup2' function is most
likely what you want.
DS
| |
| dienet 2007-07-10, 1:23 pm |
| Dnia 10-07-2007 o 14:44:54 David Schwartz <davids@webmaster.com>
napisał(a):
> The 'dup2' function is most
> likely what you want.
Or popen()
--
pozdr0
dienet
"Old C programmers never die. They're just cast into void."
| |
| Fred Kleinschmidt 2007-07-10, 7:26 pm |
|
"Jaw109" <jaw109@gmail.com> wrote in message
news:1184075615.186498.168320@d30g2000prg.googlegroups.com...
> Hi there
>
> I am a beginner for system programming, I'd like to use fork-exec
> programming to perform a "C-code compilation" and see if any
> compilation errors within ......
>
> (snip)
You might want to use popen() instead...
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing
| |
| Nick Incarnato 2007-07-12, 1:19 pm |
| On Jul 10, 2:18 pm, "Fred Kleinschmidt"
<fred.l.kleinmschm...@boeing.com> wrote:
> "Jaw109" <jaw...@gmail.com> wrote in message
>
> news:1184075615.186498.168320@d30g2000prg.googlegroups.com...
>
>
>
>
> You might want to use popen() instead...
> --
> Fred L. Kleinschmidt
> Boeing Associate Technical Fellow
> Aero Stability and Controls Computing
AVOID the popen() call. It spawns a shell process, which can be
exploited by compromising the char buffer you pass to it in popen's
first argument. Stick with fork/exec.
Nick Seidenman, CISSP
| |
| Jens Thoms Toerring 2007-07-12, 7:20 pm |
| Nick Incarnato <n6151h@gmail.com> wrote:
> AVOID the popen() call. It spawns a shell process, which can be
> exploited by compromising the char buffer you pass to it in popen's
> first argument. Stick with fork/exec.
Could you please elaborate a bit on how this would work? Wouldn't
that require that the attacker was able to install a compromized
version of /bin/sh, in which case he already would have all the
privileges he ever could hope to obtain?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Barry Margolin 2007-07-13, 1:22 am |
| In article <5fnf1cF3des9vU2@mid.uni-berlin.de>,
jt@toerring.de (Jens Thoms Toerring) wrote:
> Nick Incarnato <n6151h@gmail.com> wrote:
>
> Could you please elaborate a bit on how this would work? Wouldn't
> that require that the attacker was able to install a compromized
> version of /bin/sh, in which case he already would have all the
> privileges he ever could hope to obtain?
I think Nick was more concerned with the case where part of the command
line passed to popen() comes from an untrusted source, such as a network
client. When you merge this string into the command line you have to be
very careful to escape special characters, or they may be able to cause
unintended behavior.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Jaw109 2007-07-13, 1:22 am |
| On Jul 11, 2:18 am, "Fred Kleinschmidt"
<fred.l.kleinmschm...@boeing.com> wrote:
> "Jaw109" <jaw...@gmail.com> wrote in message
>
> news:1184075615.186498.168320@d30g2000prg.googlegroups.com...
>
>
>
>
> You might want to use popen() instead...
> --
> Fred L. Kleinschmidt
> Boeing Associate Technical Fellow
> Aero Stability and Controls Computing
Okay
My advisor said "freopen()" could be a solution....
Like this...
[code]
freopen("stdout.log", "w", stdout); // redirect stdoutput to a file
named "stdout.log"
freopen("stderr.log", "w", stderr); // redirect stderror to a file
named "stderr.log"
system("cc SomeSourceFile.c"); // the output message will be redirect
to a corresponding file
[/code]
By comparsion with calling "popen()", I need to open the file then
parse them, this would be a overhead !
If I like to redirect stderr, how should I do by calling "popen()"?
| |
| Rainer Weikusat 2007-07-13, 7:23 am |
| Barry Margolin <barmar@alum.mit.edu> writes:
> In article <5fnf1cF3des9vU2@mid.uni-berlin.de>,
> jt@toerring.de (Jens Thoms Toerring) wrote:
>
> I think Nick was more concerned with the case where part of the command
> line passed to popen() comes from an untrusted source, such as a network
> client. When you merge this string into the command line you have to be
> very careful to escape special characters, or they may be able to cause
> unintended behavior.
There are other sources of misbehaviour here. Depending on the actual
shell, the behaviour may be different because of different environment
settings, most notably, PATH. Ever had a program which worked fine
except when started by cron? And the shell eats the exit status of the
actually executed command.
|
|
|
|
|