Add a function to check if an environment variable has a given name.

This also fixes the following issue: in mixed-mode the LD_LIBRARY_PATH
variable was duplicated instead of being replaced:

    proot -Q qemu-arm ./linux-arm-rootfs

    $ unset LD_LIBRARY_PATH
    $ /host-rootfs/bin/env | grep LD_LIB
    LD_LIBRARY_PATH=/host-rootfs/lib64:/host-rootfs/usr/lib64:[...]

    $ export LD_LIBRARY_PATH=foo
    $ /host-rootfs/bin/env | grep LD_LIB
    LD_LIBRARY_PATH=foo
    LD_LIBRARY_PATH=/host-rootfs/lib64:/host-rootfs/usr/lib64:[...]

Change-Id: I3798d278713a83dccc87f8516146b7f161f75b2d
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Import Rémi's article on how to set up a Debian rootFS for PRoot.

This article was imported almost as-is, the only three changes are:

    * format is now ReST;
    * title is changed; and
    * "strong" style is changed into "fixed".

Change-Id: I1ade7114f81cf151e2f2ad56cd3a965664d1272a
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Signed-off-by: Rémi Duraffort <remi.duraffort@st.com>
Rename QUF'11 article and move it to the directory dedicated to articles.

Change-Id: I862ade38f093b4561fd5851554f34e454d16af1a
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Added new support function get_env_entry().

v2: check_variable_name() renamed into check_env_entry_name() and
    exported so as to be used both in get_env_entry() and in
    ldso_env_passthru().

Change-Id: Icf5fc5a1fcf3376ef843e4749983b563acf8b8e3
Signed-off-by: Christophe Guillon <christophe.guillon@st.com>
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Don't use the same process group for PRoot and its tracees.

When PRoot belongs to the same process group as its tracees, it might
be unintentionally killed if one of them calls "kill(0, ...".

Change-Id: I7492916e83967410f67c5adced6d49b364a4565b
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Reported-by: Mickael GUENE <mickael.guene@st.com>
Leave all but the first bare SIGTRAP unhandled.

Only the first *bare* SIGTRAP is related to the tracing loop, others are
explicitly emitted by traced processes.  This problem was exposed by the
Open POSIX Test Suite.

Change-Id: Ib1be6198c8006c5fba362f9d8e0afb1067214d61
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Avoid the first -- spurious -- SIGSTOP sent to each tracee.

The first SIGSTOP sent to each tracee is only used to notify the
tracer.  This problem was exposed by the Open POSIX Test Suite.

Change-Id: Ifc257a860757d4b355973b69a70b2f1c2ca0eaf6
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Fix x86_64 ABI support: the 5th and 6th syscall arguments were swapped.

Two syscalls were hit by this bug: linkat() and fchownat().

Change-Id: I5d605fc66387e7f2b74de08bacaad7273ebe9772
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Reported-by: Mickael GUENE <mickael.guene@st.com>
Fix wrong parameters passed to notice(), two different enum types were swapped.

GCC doesn't report this kind of problem.  Luckily both "ERROR" and
"SYSTEM" have the same value.

Change-Id: I6e3671958f5d6fb33855c5d35c40f61f8ec78bbf
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Reported-by: Clang LLVM
Revert "Don't use the same process group for PRoot and its tracees."

This reverts commit 98ab612435c2adc5fcc00b31df0fc9fe66e81439.  It
introduced a huge regression with shell-like programs (they hang).

Change-Id: I25f27bb73a3f5a2d5f83d59a456dab16668a3a08
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Remove specific support for "restart_syscall".

This specific support was written a long time ago to be able to attach
a process on-the-fly.  This feature isn't supported anymore and I wonder
what were the negative effects of this support, for instance, I saw many
"forbidden syscall" messages on Open Build Service computers.  Sadly I'm
not able to produce a test case...

Change-Id: If98986a0fe5c6eb381adfa11267e6d9f707e5230
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Ignore terminating signals + kill all tracees on abnormal termination signals.

Terminating signals are now ignored, this permits "kill(0, ...)"
without creating a dedicated process group.  Note that tracees can
still send SIGKILL and SIGSTOP to PRoot since these signals can't be
caught.  A solution would be to nullify syscalls like signal(2) when
the recipient is PRoot.

Regarding abnormal termination signals (segmentation fault, divide by
zero, ...), they are caught to ensure no tracees will stay alive
without being monitored anymore.

Signals related to tty and job control are left untouched, for the
sake of transparency.

Change-Id: Iba60fba24b4f6f5d7c12727e2327ac713341f188
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Add links latest Rémi's article and to Arch/ARM rootfs + news style for <pre>.

Change-Id: I9814f0e61fbae8c2dae2fc932103e363214381f1
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Remove the SIGSTOP test, it isn't reliable from one kernel version to another.

I did the following sanity check: the same binary of PRoot running the
same binary of this test doesn't behave the same on several Linux
distro.  In all cases the child doesn't remain stopped, it runs
(verified with strace too):

    The kernel behavior described in the previous paragraph causes a
    problem with transparent handling of stopping signals.  If the
    tracer restarts the tracee after group-stop, the stopping signal
    is effectively ignored -- the tracee doesn't remain stopped, it
    runs.  If the tracer doesn't restart the tracee before entering
    into the next waitpid(2), future SIGCONT signals will not be
    reported to the tracer; this would cause the SIGCONT signals to
    have no effect on the tracee.

    -- ptrace.2 from man-pages 3.42

However, in some cases the child's status reported to the parent is
"stopped" [1] and in other cases this status is "exited" [2].  I'm not
even sure it is a deterministic behavior.

[1]: CentOS-6/i586, CentOS-6/x86_64, Debian_6.0/x86_64,
  Mandriva_2009.1/i586, Mandriva_2009.1/x86_64, Mandriva_2010/i586,
  Mandriva_2010/x86_64, Mandriva_2010.1/i586, Mandriva_2010.1/x86_64,
  Mandriva_2011/i586, Mandriva_2011/x86_64, RedHat_RHEL-5/x86_64,
  RedHat_RHEL-6/i586, RedHat_RHEL-6/x86_64, SLE_10_SDK/i586,
  SLE_11_SP2/i586, ScientificLinux_6/i586, ScientificLinux_6/x86_64,
  openSUSE_12.1/i586, openSUSE_12.1/x86_64, openSUSE_Factory/i586,
  openSUSE_Tumbleweed/x86_64, xUbuntu_8.04/i586, xUbuntu_9.04/i586

[2]: CentOS_CentOS-5/i586, CentOS_CentOS-5/x86_64, Debian_5.0/i586,
  Debian_5.0/x86_64, Debian_6.0/i586, Fedora_15/i586,
  Fedora_15/x86_64, Fedora_16/i586, Fedora_16/x86_64,
  RedHat_RHEL-4/i586, RedHat_RHEL-4/x86_64, RedHat_RHEL-5/i586,
  SLE_10_SDK/x86_64, SLE_11/i586, SLE_11/x86_64, SLE_11_SP1/i586,
  SLE_11_SP1/x86_64, SLE_11_SP2/x86_64, openSUSE_11.1_Evergreen/i586,
  openSUSE_11.1_Evergreen/x86_64, openSUSE_11.3/i586,
  openSUSE_11.3/x86_64, openSUSE_11.4/i586, openSUSE_11.4/x86_64,
  openSUSE_Factory/x86_64, openSUSE_Tumbleweed/i586,
  xUbuntu_10.04/i586, xUbuntu_10.04/x86_64, xUbuntu_10.10/i586,
  xUbuntu_10.10/x86_64, xUbuntu_11.04/i586, xUbuntu_11.04/x86_64,
  xUbuntu_11.10/i586, xUbuntu_11.10/x86_64, xUbuntu_8.04/x86_64,
  xUbuntu_9.04/x86_64, xUbuntu_9.10/i586, xUbuntu_9.10/x86_64

Change-Id: I0739f032ba73c349c75cb2a79f92e06e93e08b24
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Force utsname.machine to "i686" for 32-bit programs running on 64-bit systems.

YUM on Fedora computes repositories URL from utsname.machine, that
means it tried to fetch packages from i386 repositories, which are not
really maintained (no "libxml2-python" package for instance).

Change-Id: I1a705ab7da822ca153cbb9c08800ed54d6e1d4dc
Signed-off-by: Cédric VINCENT <cedric.vincent@st.com>
Prepare release v1.9.

Change-Id: I3c282546d0b7de5fda414426225c6e109a3de68d