ID: 41518 Updated by: [EMAIL PROTECTED] Reported By: ruben dot willmes at emil2001 dot de -Status: Assigned +Status: Closed Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 5.2.2 Assigned To: tony2001 New Comment:
This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2007-06-18 18:41:24] paul at moonkhan dot org @Ruben Running PHP 5.2.3 on Redhat Enterprise Linux 4 I get the following: #php -d open_basedir=/tmp -r 'var_dump(file_exists("/tmp/nosuch"));' bool(false) But if I switch /tmp to /tmp/ (ie, with trailing slash): #php -d open_basedir=/tmp/ -r 'var_dump(file_exists("/tmp/nosuch"));' PHP Warning: file_exists(): open_basedir restriction in effect. File(/tmp/nosuch) is not within the allowed path(s): (/tmp/) in Command line code on line 1 Warning: file_exists(): open_basedir restriction in effect. File(/tmp/nosuch) is not within the allowed path(s): (/tmp/) in Command line code on line 1 bool(false) We can eliminate this problem in our environment if we remove the trailing slashes from our open_basedir settings but that's not how open_basedir was intended to work, since trailing slashes prevent "wildcarding". For example, "/tmp" matches "/tmpfoo" and "/tmpbar" but "/tmp/" should only match, well, /tmp/. -Paul ------------------------------------------------------------------------ [2007-06-01 00:02:29] phpbugs at thequod dot de This might be related to bug #39123, where open_basedir=/tmp/ started to fail, as internally only "/tmp" (without trailing slash) got considered. (http://bugs.php.net/bug.php?id=39123) ------------------------------------------------------------------------ [2007-05-31 12:40:31] ruben dot willmes at emil2001 dot de Your example is correct, that does work, but what if you change the following: Instead of #php -d open_basedir=/tmp -r 'var_dump(file_exists("/tmp/nosuch"));' try #php -d open_basedir=/tmp/ -r 'var_dump(file_exists("/tmp/nosuch"));' Notice the slash behind "open_basedir=/tmp/". With that you get Warning: file_exists(): open_basedir restriction in effect. File(/tmp/ nosuch) is not within the allowed path(s): (/tmp/) in Command line code on line 1 bool(false) ------------------------------------------------------------------------ [2007-05-31 11:06:13] [EMAIL PROTECTED] I don't think I get what you're talking about: # ls -l /tmp/nosuch ls: cannot access /tmp/nosuch: No such file or directory #php -d open_basedir=/tmp -r 'var_dump(file_exists("/tmp/nosuch"));' bool(false) No warning whatsoever. ------------------------------------------------------------------------ [2007-05-30 20:20:58] ruben dot willmes at emil2001 dot de Sorry, but i have to reopen this bug again. Thx for the reply, Tony, but i don't think you understood me. I don't want to generally remove this error message, it's just under your OWN open_basedir, where you shouldn't get this message since you should be able to check whether the file exists under your OWN open_basedir, or am i wrong? Let's make an example: Two users, user1 and user2, both locked in their homedirs with open_basedir: /home/user1/ /home/user2/ Both have one file in their directory, let's call it test.php Now, if user1 checks whether test.php exists, he get's a true, as well as user2. If user1 checks user2's test.php, he'll get a false and an open_basedir warning since he's out of his open_basedir. That's correct. But what if user1 checks a file called test2.php under his own directory, /home/user1/? Should he get an open_basedir error? In my eyes he should only get a 'false' as the file does not exist, but no open_basedir warning, since he's still in his own open_basedir. In the recent PHP5 release (5.2.2) one get's an open_basedir warning if you check a non-existent file under your OWN open_basedir. In a previous release the message was not present (i think it was 5.2.0 or 5.2.1). so, please reconsider this bug ------------------------------------------------------------------------ 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 http://bugs.php.net/41518 -- Edit this bug report at http://bugs.php.net/?id=41518&edit=1
