Description
Currently, there is no way (in Symfony) to configure the fallback directory for the LockHandler when deploying a third-party Symfony-based app. Unless the developer has hard-coded a specific directory in the constructor calls, the LockHandler will fall back on the system's temporary directory as provided by sys_get_temp_dir().
This can lead to problems in some shared hosting configurations when sys_get_temp_dir() doesn't provide a useful value and the corresponding php.ini directive sys_temp_dir cannot be configured by the user. That may sound like a fringe scenario but I know of one fairly big European provider that uses the following setup on their shared servers:
sys_get_temp_dir()defaults to/tmpbecausesys_temp_dirhas no value assigned to it, AND- PHP is blocked from writing to
/tmpfor security reasons.
Currently, the only way to adapt a third-party Symfony-based app to such a setup is to "hack" the source code, e.g. by replacing sys_get_temp_dir() with some absolute path or by setting the TMP, TEMP and TMPDIR environment variables at runtime. It would be much easier if a fallback directory for the LockHandler could be specified centrally in a Symfony configuration file. The LockHandler could then use the following fallback sequence:
- Use any directory passed in the constructor call.
- Otherwise, use any directory specified in the configuration file.
- Otherwise, use
sys_get_temp_dir()to get the system's default temporary directory.
To be clear: I'm not expecting Symfony to anticipate every weird server setup. What I'm saying is that, since the usability of sys_get_temp_dir() depends on the server setup, and precisely because Symfony cannot anticipate all possible server setups, it should provide a way of configuring a fallback directory in case sys_get_temp_dir() fails.