Who knew, well I suppose it is in a manual somewhere.
Took me a while to figure out what this was.
The answer was at http://stackoverflow.com/questions/12206857/php-cant-read-file-on-var-tmp
I have Apache rewite rules that run a bash script from /cgi-bin/ and write to a file in /var/tmp. A also have a PHP webpage that reads the file in /var/tmp, unfortunately under the F20 release of systemd /var/tmp is a movable location when it is accessed from under Apache.
Knowing the file name I did a search for it. And found it in unexpected locations, for example
/var/tmp/systemd-httpd.service-XQe2EnM/tmp/blacklist.log /var/tmp/systemd-httpd.service-XBx5E16/tmp/blacklist.log
Now thats obviously by design.
The file is supposed to be appended to, but it looks like when httpd is restarted by systemd writes/reads to /var/tmp go to a dynamically remapped folder so I am ending up with multiple files in random locations that are being appended to.
An example of the PHP code that reads the file and the bash code that writes the file is below
/* PHP that reads the file */
$filename = "/var/tmp/blacklist.log";
$databuf = "";
if (file_exists($filename)) {
if (is_readable($filename)) {
if ($databuf = file_get_contents( $filename )) {
echo "<pre>$databuf</pre>";
}
}
}
# bash script code that appends to the file
LOGFILE="/var/tmp/blacklist.log"
echo "Message I want logged" >> ${LOGFILE}
So how to get the damn scripts writing/reading where they should ?.
As mentioned in the post I linked to above it is to do with systemd private temp directories.
vi /usr/lib/systemd/system/httpd.service change 'PrivateTmp=true' to 'PrivateTmp=false' systemctl daemon-reload systemctl restart httpd.service
And that fixes it for httpd/apache anyway.
However using private temp directories does seem like a good idea from a security perspective, thats why they were introduced in the first place. So I will try to find time to rewrite all my scripts to store semi-permanent data somewhere else… outside the webserver directories as external scripts that use the file have no need to traverse the webserver directories, so I guess more pain with SELinux lies ahead.
