On 29/10/2013 10:10, Michael Orlitzky wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/28/2013 04:10 PM, Reindl Harald wrote:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
oh no - do *not* place the sesiondata anywhere inside open_basdir this is one of the badest things you can do because any otherwise harmless script bypassed whatever security restriction will be able to read *any* session data
You have a point, but I wouldn't go as far as to say it's one of the worst things you can do. If a vulnerable PHP script allows an attacker to (at least try to) read arbitrary files, then it's possible to read session data that lies within open_basedir. Note that they can already read your database credentials out of config.php at that point.
But, if you put the session data under open_basedir, then it's easy to restrict access to the entire /var/www/example.com hierarchy to the one user that needs it: www.example.com. In the scenario I described, I'm able to tell our customers that their websites are "physically" separated from our other customers.
If there's a vulnerability in someone else's site, the kernel (via filesystem ACLs) will prevent it from affecting yours. The web user for example.NET truly cannot even traverse /var/www/example.COM, where everything important to you is stored. This is robust against Apache, Ruby, Python, etc. vulnerabilities as well -- not just PHP.
I already mentioned that I don't trust PHP. Our sites would be just as secure if open_basedir stopped working tomorrow, since the filesystem ACLs are what we trust to work. So, we trade the potential to read sessions for that peace of mind. Not trying to downplay your complaint, just pointing out another POV.
Some time ago, we too, evaluated the pros and cons given our design, and we too, decided on the lesser evil and keep it under open_basedir, have done for many many years without problem, of course I'm not so naive to think it may never one day be a problem for a single host, when running shared hosting there are always risks, in everything.