Output redirection from shell script in Linux is redirected to weird location once called from PHP's exec()

Question

There is a shell (bash) script, living on CentOS with SELinux set to Permissive, and it has only one purpose - to write something to file:

[root@centos ~]$ cat /var/www/html/test.php
<?php
$output=shell_exec("/opt/sms/script.sh");
var_dump($output);
?>
[root@centos ~]$ cat /opt/sms/script.sh
#!/bin/bash

whoami > /tmp/a.txt

cat /tmp/a.txt
[root@centos ~]$ php -f /var/www/html/test.php
string(5) "root
"
[root@centos ~]$

All good so far! But now let's call it via PHP's exec, using Apache an you'll get in your browser the following:

string(7) "apache "

which is still good until you do this:

[root@centos ~]$ cat /tmp/a.txt
root
[root@centos ~]$

what?

And then you do this:

[root@centos ~]$ find / -name a.txt 2>/dev/null
/tmp/systemd-private-689e87297de1452e98dcfaa5bd686a1f-httpd.service-gMJKi0/tmp/a.txt
/tmp/a.txt
[root@centos ~]$ cat /tmp/systemd-private-689e87297de1452e98dcfaa5bd686a1f-httpd.service- 
gMJKi0/tmp/a.txt
apache
[root@centos ~]$ cat /tmp/a.txt
root
[root@centos ~]$

Question: why is the output being written to that /tmpp/systemd-*/tmp.a.txt file instead of simple /tmp/a.txt ? I provided ABSOLUTE path, which is supposed to serve the very obvious purpose. How/where is it controlled, that my output is written elsewhere?

Answer 1

This is often known as a "chroot jail", after the chroot syscall (and shell command) that lets you set the root directory of a process to something else. This effectively quarantines the process into a certain subdirectory. All absolute paths will be interpreted relative to this root directory.

It's a classic and well known security technique. If one of your PHP scripts is exploitable, an attacker will nominally be restricted to messing with files in the chroot jail, while leaving the rest of the system isolated.

( systemd likely uses Linux namespaces rather than chroot itself, but the idea is the same)