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)?

On Jul 10, 6:53 am, Jaw109 <jaw> 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

"Jaw109" <jaw109> wrote in message
news:8320
> 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...

Dnia 10-07-2007 o 14:44:54 David Schwartz <davids>
napisa³(a):

> The 'dup2' function is most
> likely what you want.

Or popen()

On Jul 10, 2:18 pm, "Fred Kleinschmidt"
<fredlkleinmschm> wrote:
> "Jaw109" <jaw> wrote in message
>
> news:8320
>>
>
> 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

Nick Incarnato <n6151h> 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

In article <5fnf1cF3des9vU2>,
jt (Jens Thoms Toerring) wrote:

> Nick Incarnato <n6151h> 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?

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.

On Jul 11, 2:18 am, "Fred Kleinschmidt"
<fredlkleinmschm> wrote:
> "Jaw109" <jaw> wrote in message
>
> news:8320
>>
>
> 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()"?

Barry Margolin <barmar> writes:
> In article <5fnf1cF3des9vU2>,
> jt (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.