vfork() not intercepted

Found in: 1.19
CategoryFixed

vfork() is not intercepted by PlashGlibc. The consequence is that a new FsOp object and a new connection are not set up. Not having a new FsOp means that the cwd is not properly isolated to a subprocess. Not setting up a new connection means that a connection is shared between processes. That means that if processes use the connection concurrently, the messages could become mixed up and corrupted, and the replies could be mixed up.

GNU make uses vfork(), so this can be demonstrated with make:

$ cat Makefile
all:
        pwd; cd /
        pwd
$ cd /usr
$ pola-run -fw / -e make
pwd; cd /
/usr
pwd
/

make runs each command through the shell in a subprocess, so the correct behaviour is:

$ make
pwd; cd /
/usr
pwd
/usr

This was a regression caused by Story6.

Note that on Linux, vfork() was equivalent to fork() until about 2.2.0, when a separate vfork() system call was introduced. With PlashGlibc, vfork() should be equivalent to fork().

Dependencies

This issue is fixed but awaiting a fix for PlashIssues/Lib64Directory so that the following test can be added to functional_test.py:

    def test_chdir_in_forked_process(self):
        temp_dir = os.getcwd()
        proc = subprocess.Popen(
            [self._pola_run, "-B", "-fw", temp_dir,
             "-f", "/lib64", # TODO
             "-e", "/bin/bash", "-c", """
set -e
echo Foo > test_file
mkdir test_dir
bash -c 'cd test_dir && echo In subprocess && pwd'
cat test_file
pwd
"""],
            stdout=subprocess.PIPE)
        stdout, stderr = proc.communicate()
        check_subprocess_status(proc.wait())
        self.assertEquals(stdout, "In subprocess\n%s/test_dir\nFoo\n%s\n"
                          % (temp_dir, temp_dir))