It's to simplify the interface. The alternative to fork and exec would be something like Windows' CreateProcess function. Notice how many parameters CreateProcess has, and many of them are structs with even more parameters. This is because everything you might want to control about the new process has to be passed to CreateProcess. In fact, CreateProcess doesn't have enough parameters, so Microsoft had to add CreateProcessAsUser and CreateProcessWithLogonW.
With the fork/exec model, you don't need all those parameters. Instead, certain attributes of the process are preserved across exec. This allows you to fork, then change whatever process attributes you want (using the same functions you'd use normally), and then exec. In Linux, fork has no parameters, and execve has only 3: the program to run, the command line to give it, and its environment. (There are other exec functions, but they're just wrappers around execve provided by the C library to simplify common use cases.)
If you want to start a process with a different current directory: fork, chdir, exec.
If you want to redirect stdin/stdout: fork, close/open files, exec.
If you want to switch users: fork, setuid, exec.
All these things can be combined as needed. If somebody comes up with a new kind of process attribute, you don't have to change fork and exec.
As larsks mentioned, most modern Unixes use copy-on-write, so fork doesn't involve significant overhead.
Following the updated information, you should have them do private/public key pairs and inside the .ssh/authorized_keys file set it to only run script.php file. You shouldn't rely on the .bashrc for protection, especially since that is needed to initialize the environment.
Best Answer
First, process creation is rarely a useful event to log and it's irrelevant for security (except for resource limiting). I think you mean to hook the execution of programs, which is done by
execve, notfork.Second, the use cases you cite are usually best served by using existing mechanism made for that purpose, rather than rolling your own.
auditctlman page has examples; as I explained above the system call you'll want to log isexecve).If you want to modify the way one specific program calls other programs, without affecting how other programs behave, there are two cases: either the program is potentially hostile or not.
PATH. If the program uses absolute paths that aren't easy to configure, on a non-antique Linux system, you can run it in a separate mount namespace (see also kernel: Namespaces support). If you really need fine control, you can load a library that overrides some library calls by invoking the program withLD_PRELOAD=my_override_library.so theprogram. See Redirect a file descriptor before execution for an example. Note that in addition toexecve, you'll need to override all the C library functions that callexecveinternally, becauseLD_PRELOADdoesn't affect internal C library calls. You can get more precise control by running the program underptrace; this allows you to override a system call even if it's made by a C library function, but it's harder to set up (I don't know of any easy way to do it).