You don't mention which OS you're using, but in Richard Stevens'
_Advanced Programming in the UNIX Environment_, on p.189 he states:
"Many current implementations don't perform a complete copy of the
parent's data, stack, and heap, since a fork is often followed by an
exec. Instead, a technique called copy-on-write (COW) is used."
This does exactly what you'd think it would--shared heap is made
read-only, and additional memory is allocated only when the parent or
child try to modify data.
So, forking an entire server process isn't as bad as you'd think.
-Mike
At 1:39 PM -0800 11/28/00, Paul wrote:
Hi all.
I'm writing module code which (for backward compatibility with the CGI
it's replacing) needs to be able to execute commands from a file.
(~urgh~) The files have usually been ksh and/or Perl. Commonly, they
contain a directive to execute a line of shell script.
Ideally, such commands will be replaced with equivelent perl code which
could simply be eval()'d, but I'm concerned that one of my coworkers
might write his perl code with backticks in it (like `grep foo *.bar`)
instead of writing the few extra lines of code, particularly since we
have a lot of legacy code in several languages (such as ksh functions).
Wouldn't that effectively fork an entire server process before exec'ing
the qx//? And is there any simple way to prevent that, or any simple
alternative aside from a big stick?
(a stoopid question -- Doesn't a Perl eval() with backticks do a full
blown program fork and exec, too?)
Also, I realize the security holes this might present, but the files in
question are never influenced by user input. Security isn't the
question -- just the fork.
Thanks a mil,
Paul
__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
