Edit report at https://bugs.php.net/bug.php?id=52065&edit=1
ID: 52065
Comment by: rtrtrtrtrt at dfdfdfdf dot dfd
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:
> 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
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2020-11-12 15:04:19] php dot stephan at lippe-net dot de
Cool, a bug described in 2010 not even fixed in PHP 8.0RC3.
That's a statement!
------------------------------------------------------------------------
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