https://bugs.php.net/bug.php?id=52312

14 years ago by Reindl Harald — view source — reply

unread

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

14 years ago by Pierre Joye — view source — reply

unread

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

14 years ago by Reindl Harald — view source — reply

unread

Am 17.08.2011 13:14, schrieb Pierre Joye:

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.

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 <Diretory>-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"

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

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

14 years ago by johannes@schlueters.de — view source — reply

unread

Am 17.08.2011 13:14, schrieb Pierre Joye:

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.

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 <Diretory>-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

14 years ago by Pierre Joye — view source — reply

unread

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 <Diretory>-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).

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

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

14 years ago by Reindl Harald — view source — reply

unread

Am 17.08.2011 14:25, schrieb Pierre Joye:

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 <Diretory>-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).

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

14 years ago by Pierre Joye — view source — reply

unread

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

14 years ago by Reindl Harald — view source — reply

unread

Am 17.08.2011 16:25, schrieb Pierre Joye:

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

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