php Question posted in
Official manual can be found here.

How to write boot persistent files outside the document root with a PHP web application?

The systemd PrivateTmp option for a php-fpm service affects write access to files outside the document root.

e.g. Red Hat Enterprise Linux 9 and PHP 8.2.13

For example, if var/tmp/myApp (say) is used for temporary files that are required to outlive a reboot, write access is prevented if true and permitted otherwise.
The systemd manual describes how a process specific subtree is used and mounted instead of a vanilla /tmp. It also refers to var/tmp, but I haven’t seen any evidence that this happens. If it did, wouldn’t this be a contradiction – because /tmp is cleared on boot?

Because I wish all files inside the document root to be read-only for reasons of security, how should php.ini and the php-fpm service be configured to permit write access to other paths, such as /var/tmp/myApp with PrivateTmp = true?

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I’d prefer not to get too hung up on the semantics of what constitutes a temporary file or not. My question originated from PHP error logs tempnam(): file created in the system's temporary directory. Various tests had led me to believe that the document root was a factor. However, on more reflection and experimentation, I now understand that this was incorrect and it’s a general question about systemd. What is the point of having both sandbox versions of /tmp and /var/tmp if they are both cleared on boot? It just seems contrary to the convention of persistence for /var/tmp; of course systemd would then need some kind of unique service id to honour it.


  2. 0

    temporary files that are required to outlive a reboot

    This is contradictory. If you need files to outlive a reboot, then, by definition, they’re not temporary.

    The general mechanism you’d use to solve this issue is to have your document root one level down from your project root, and then use a project-specific "temporary" directory at the project root. For example, consider the directory layout of this project:

    /path/to/project
├── log
│   └── 20240904.log
├── public
│   ├── images
│   │   └── logo.png
│   ├── index.php
│   └── js
│       └── app.js
├── src
│   ├── Model
│   │   └── User.php
│   └── Service
│       └── Foo.php
└── var
    └── cache
        └── abcde

    If you now point your document root at the public subdir rather than the /path/to/project dir, then the web server process will have access to only the files below that point, which are only the files that will be directly served to clients. Everything else, including PHP source, lives outside the document root, and the web server doesn’t even know of its existence.

    But the php-fpm process runs (should, at least) as a different user than the web server process, so you can now control the access separately. For example, the web server user would only have read access to public while the php-fpm user would have write access to var/cache. This would allow your PHP code to arbitrarily read/write files in var/cache that would survive reboots, but the web client would never be able to directly request those files via some url like http://yoursite.com/var/cache/abcde.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search