# https://bugs.php.net/bug.php?id=52312 - Thread: https://externals.io/message/54639 - Original archive: https://news-web.php.net/php.internals/54639 - Started by Reindl Harald on 2011-08-16T21:29:55+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54639 — Reindl Harald — 2011-08-16T21:29:55+00:00 URL: https://externals.io/message/54639#54639 Hi https://bugs.php.net/bug.php?id=52312 does the security-problem in combination with open_basedir only occur if there are symlinks created? * i guess in most secure setups "symlink" is disabled * give us a option to bypass the check in such environments --- ## #54642 — Pierre Joye — 2011-08-17T11:14:02+00:00 URL: https://externals.io/message/54639#54642 · In reply to: #54639 > Hi > > https://bugs.php.net/bug.php?id=52312 > > does the security-problem in combination with open_basedir only > occur if there are symlinks created? > > * i guess in most secure setups "symlink" is disabled For what I can see, almost no setup disables the symlink functions in php, even less in the shell. > * give us a option to bypass the check in such environments Well, there are other better ways to control access than relying on open_basedir. Permissions are on, that's why I would not add special cases here. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54643 — Reindl Harald — 2011-08-17T12:13:00+00:00 URL: https://externals.io/message/54639#54643 · In reply to: #54642 Am 17.08.2011 13:14, schrieb Pierre Joye: > > > […] > > For what I can see, almost no setup disables the symlink functions in > php, even less in the shell. defaults on all servers i maintain since 10 years "popen" is disabled per vhost with "php_admin_value suhosin.executor.func.blacklist" since "disable_functions" is to dumb working on -directive disable_functions = "exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink" > > […] > > Well, there are other better ways to control access than relying on > open_basedir. Permissions are on, that's why I would not add special > cases here if you are hosting some hundret domains there are not really better ways since you will not add hundrets of system-users while you have to deal with FTP/SFTP and exactly these setups for some hundret domains would benefit most of the realpath-cache --- ## #54644 — johannes@schlueters.de — 2011-08-17T12:25:18+00:00 URL: https://externals.io/message/54639#54644 · In reply to: #54643 > > Am 17.08.2011 13:14, schrieb Pierre Joye: > > […] > > defaults on all servers i maintain since 10 years > "popen" is disabled per vhost with "php_admin_value suhosin.executor.func.blacklist" > since "disable_functions" is to dumb working on -directive > > disable_functions = "exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, > proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, > posix_setuid, mail, symlink" All that doesn't mean there can't be symlinks. Maybe they can't be created using PHP but they still could exist. johannes --- ## #54645 — Pierre Joye — 2011-08-17T12:25:46+00:00 URL: https://externals.io/message/54639#54645 · In reply to: #54643 hi, > defaults on all servers i maintain since 10 years > "popen" is disabled per vhost with "php_admin_value suhosin.executor.func.blacklist" > since "disable_functions" is to dumb working on -directive > > disable_functions = "exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, > proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, > posix_setuid, mail, symlink" symlink is not disabled in most ISPs I work with or used (and that's quite a lot). > > […] > > if you are hosting some hundret domains there are not really > better ways since you will not add hundrets of system-users > while you have to deal with FTP/SFTP > > and exactly these setups for some hundret domains would benefit > most of the realpath-cache Besides the arguments already stated in the bug report, there is no chance that we will change this. All past attempts to "optimize" open_basedir (and before safemode) has ended as shooting ourselves in the knees. It is still too slow for your needs? Don't use it and rely on system's solutions (or web server, like on IIS or many fastcgis). It sounds bad but that's how it is. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54646 — Reindl Harald — 2011-08-17T13:16:51+00:00 URL: https://externals.io/message/54639#54646 · In reply to: #54645 Am 17.08.2011 14:25, schrieb Pierre Joye: > hi, > > > > > […] > > symlink is not disabled in most ISPs I work with or used (and that's > quite a lot). most setups out there are unsecure as hell this is no reason to ignore proper configured > Besides the arguments already stated in the bug report, there is no > chance that we will change this. All past attempts to "optimize" > open_basedir (and before safemode) has ended as shooting ourselves in > the knees. if "realpath_cache" would be a little smarter and include a hash on the open_basedir there would be nothing to change on open_basedir side > It is still too slow for your needs? Don't use it and rely > on system's solutions (or web server, like on IIS or many fastcgis). > It sounds bad but that's how it is the point is that "realpath_cache" is simply useless show me one well thought setup without open_basedir and after that think about your definition of "well thought" if you think you found one - even with fastcgi and sepearted users there should never be any access outside the docroot possible so if "realpath_cache" will not be fixed in combination with "open_basedir" it can be totally removed also for the handful of non-shared hosts --- ## #54647 — Pierre Joye — 2011-08-17T14:25:43+00:00 URL: https://externals.io/message/54639#54647 · In reply to: #54646 > so if "realpath_cache" will not be fixed in combination with "open_basedir" > it can be totally removed also for the handful of non-shared hosts Again, as stated many times already, php is not alone on a webserver. Many other tools or apps can and will create symbolic links, on purpose or not (flaws). There is no chance that we will ever cache open_basedir checks. There are alternative solutions as well. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54652 — Reindl Harald — 2011-08-17T17:01:48+00:00 URL: https://externals.io/message/54639#54652 · In reply to: #54647 Am 17.08.2011 16:25, schrieb Pierre Joye: > > > > […] > > Again, as stated many times already, php is not alone on a webserver. > Many other tools or apps can and will create symbolic links, on > purpose or not (flaws). There is no chance that we will ever cache > open_basedir checks. There are alternative solutions as well again: if someone knows his setup he knows if anything else could create symlinks and as long there is no access outside PHP for 250 domains on our mainserver using all the same cms and only two admins have access it is pretty safe skip the symlink-check there is NO possibility to get ever a symlink in a webspace