Bug #52065 [Com]: Warning about open_basedir restriction while accessing a file as directory

Edit report at https://bugs.php.net/bug.php?id=52065&edit=1 ID: 52065 Comment by: ihab dot elhawary at itpingo dot com Reported by: manuel at mausz dot at Summary: Warning about open_basedir restriction while accessing a file as directory Status: Verified Type: Bug Package: Safe Mode/open_basedir Operating System: Unix PHP Version: 5.6.8 Block user comment: N Private report: N New Comment: Warning: file_exists(): open_basedir restriction in effect. File(ReallySimpleCaptcha.php) is not within the allowed path(s): (/www/wwwroot/itpingo.com/:/tmp/) in /www/wwwroot/itpingo.com/wp-content/plugins/minimal-coming-soon-maintenance-mode/framework/public/include/misc/geoip/autoload.php on line 39 Previous Comments: ------------------------------------------------------------------------ [2021-05-20 10:54:02] rtrtrtrtrt at dfdfdfdf dot dfd > why not simply change the error > message? because any message is a problem to begin with and more important: in most of the cases you get a message that a path which is obviously within open_basedir isn't you could even check that and be silent given that when i see that as human with the blink of an exe why shouldn't a computer? > Of course, one may argue that "file checking" functions, such as > is_readable() or is_file() should not warn at all, but simply > rreturn false, but again, that would require to modify the > existing funtion and *that* is the point after decades where this annoying behavior exists - wenn i ask from inside the application if a file exists i don't care why i can't reach it (don't exist, no permissions, open_basedir) especially on systems with error_reporting E_ALL on purpose and sending twice per hours log collections with a "fix it" policy it's really annoying and when you also have a don't use @ for error supression policy you are doomed ------------------------------------------------------------------------ [2021-05-20 10:50:07] cmb@php.net Related To: Bug #81042 ------------------------------------------------------------------------ [2021-05-20 10:48:03] cmb@php.net > […] but it might have security implications […] Indeed, it would. Passing FALSE as 5th parameter to expand_filepath_with_mode() actually means CWD_EXPAND, and that would not resolve symlinks. A possible solution for the issue would be to change php_check_specific_open_basedir() so that it returns different values for failure (currently it always returns -1, what should actually be FAILURE), so that the caller could distinguish between an actual open_basedir violation, and an invalid path (as is the case here; files can't have subdirectories). However. the functon is exported, so changing the result values would be a BC break (and a rather delicate at that). An alternative would be to introduce another function, say php_check_specific_open_basedir_ex() which gives more detailed failure information, but frankly, why not simply change the error message? Of course, one may argue that "file checking" functions, such as is_readable() or is_file() should not warn at all, but simply rreturn false, but again, that would require to modify the existing funtion, or to introduce a new one, because currently there is no such distintion when checking for potential open_basedir violations. A global flag to the rescue? ------------------------------------------------------------------------ [2021-05-18 18:11:29] bugs-php dot a2 at x25 dot pl cat a.php <? ini_set("open_basedir","/home/naox/public_html/test"); mkdir("/home/naox/public_html/test"); php a.php Warning: mkdir(): open_basedir restriction in effect. File(/home/naox/public_html/test) is not within the allowed path(s): (/home/naox/public_html/test) in /home/naox/public_html/naox.vipserv.org/a.php on line 3 ------------------------------------------------------------------------ [2021-05-15 18:57:57] requinix@php.net Related To: Bug #81042 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52065 -- Edit this bug report at https://bugs.php.net/bug.php?id=52065&edit=1