php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15801 unjustified open_basedir restriction on copy()
Submitted: 2002-02-28 20:07 UTC Modified: 2005-01-31 23:13 UTC
Votes:11
Avg. Score:4.9 ± 0.3
Reproduced:11 of 11 (100.0%)
Same Version:5 (45.5%)
Same OS:5 (45.5%)
From: vedad at kajtaz dot net Assigned:
Status: No Feedback Package: Safe Mode/open_basedir
PHP Version: 4.1.2 OS: linux rh
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: vedad at kajtaz dot net
New email:
PHP Version: OS:

 

 [2002-02-28 20:07 UTC] vedad at kajtaz dot net
Hello,

I've got a weird open_basedir restriction error on copy() of an uploaded file. This occurs with php4.1.2, after upgrading from the old 4.0.4pl1, which didn't have the problem. php.ini and apache configuration were unchanged.

Virtual host settings:
php_admin_value open_basedir /path/to/website/
php_admin_value upload_tmp_dir /path/to/website/temp

I'm now getting an error when file is being copied from /path/to/website/temp/<phptempfile> to /path/to/website/somewhereelse/

Error label:

Warning: open_basedir restriction in effect. File is in wrong directory in /path/to/website/somescript.phtml on line 1055

As copy-source, copy-destination and tmp folder are all within open_basedir, I really don't get the problem.
Am I missing something?

Please note that in my case, /path/to/website is a symbolic link to /mnt/mountpoint/to/website, but i had no more success by putting the "real" path into open_basedir section.

Thanx,
-- vedad

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-28 20:48 UTC] vedad at kajtaz dot net
I've done some tests, and this is not specific to uploaded file. The copy() doesn't work at all any more, always giving open_basedir error.
I've checked phpinfo() output from faulty scripts, and open_basedir paths are correct.

Please let me know if you need more info...

-- vedad
 [2002-02-28 21:32 UTC] vedad at kajtaz dot net
Hi again,

i've got the same problem with 4.1.0 with mime upload patch...
While uploaded-file-copy may be circumvented with move_uploaded_file, i found no solution for copying not-uploaded files from one place to another. Note i'm always using full path in copy() and move_uploaded_file(), and that all paths are within open_basedir folder...

I've got no choice but downgrading even more... :(
 [2002-02-28 22:07 UTC] rasmus@php.net
Well, the reason it works in 4.0.4 is that no open_basedir check is done at all on copy() in that version.  It is wide open.  Now the check is done, and yes, in your case it is due to the symlink you have.  The open_basedir check is currently not very good at dealing with symlinked directories.
 [2002-02-28 22:10 UTC] vedad at kajtaz dot net
Okay, i finally got it to work...
copy() doesnt seem to like symbolic links... when *both* open_basedir and copy(path1, path2) paths are set to the "real" path, copy works...
However, that's still weird, as referencing files with symlinked path by other means (auto_prepend_file and upload_tmp_dir config directives and include() ) works without raising open_basedir error...
and also because this was working prior to 4.0.6, and, imha, it doesnt make things more secure than before.
 [2002-02-28 22:14 UTC] vedad at kajtaz dot net
okay, i get the point...

but what about include() and upload_tmp_dir ?
if there were using the same mechanism as copy() (sorry i never had much to look inside php source and verify by myself), they'd raise an error too, right?
(they still point to symlinked path, and they still work, unlike copy() )
 [2002-03-01 02:34 UTC] rasmus@php.net
The reason for the difference comes down to a difference in what happens when a resource that exists is checked via realpath() vs. a resource that does not exist.  Often on a copy() operation the source path exists, but the target doesn't.  That's obviously not always the case.  The open_basedir check needs to be made more advanced and should detect if the resource it is checking does not exist in which case it should step back one level and check that path.  
If I fell inspired I'll fix it, but if someone else wants to, by all means...
 [2002-11-25 08:37 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I am unable to replicate the problem using the latest CVS.
 [2002-12-06 19:12 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2005-04-24 22:17 UTC] php at kobaz dot net
PHP version 4.3.10

Using various file operations on a file that does not exist will produce an open_basedir restriction violation.

Example 1:

set open_basedir to "/home/ryan/public_html"

script 1:

stat('/home/ryan/public_html/a');  // a is a non-existant file

output:

Warning: stat(): open_basedir restriction in effect. File(/home/ryan/public_html/a) is not within the allowed path(s): (/home/ryan/public_html) in /home/ryan/public_html/a.php on line 3


Example 2:

set open_basedir to "/home/ryan/public_html:/tmp"

script 2:

echo stat('/home/ryan/public_html/images/articles/'); // this is successful
copy('/tmp/phpTqhjMx','/home/ryan/public_html/images/articles/new.jpg');  // /tmp/phpTqhjMx exists,  new.jpg does not

output:

Array

Warning: copy(): open_basedir restriction in effect. File(/home/ryan/public_html/images/articles/new.jpg) is not within the allowed path(s): (/home/ryan/public_html:/tmp) in /home/ryan/public_html/test.php on line 4
 [2006-07-17 21:28 UTC] rl at brabbel dot net
I've experienced the same problem, when trying to install gallery2 with open_basedir in effect.

mkdir and tempnam do not work as they should.

I'm really wondering that this bug still exists, as it is easily reproduceable.

Warning: mkdir(): open_basedir restriction in effect. File(/var/vhosts/mydomain/gallery-data/cache/entity/0/5) is not within the allowed path(s): (/var/vhosts/mydomain/:/usr/share/gallery2/) in /usr/share/gallery2/modules/core/classes/GalleryPlatform.class on line 624

The path /var/vhosts/mydomain is not a symlink, nor any of the subdirs below it, so all operations are happening on real dirs/files.

It would be a big win for php to get that stuff sorted out.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 17:01:30 2024 UTC