#15801 [Opn->Fbk]: unjustified open_basedir restriction on copy()

ID: 15801 Updated by: iliaa@php.net Reported By: vedad@kajtaz.net -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: linux rh PHP Version: 4.1.2 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2002-03-01 02:34:26] 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-02-28 22:14:46] vedad@kajtaz.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-02-28 22:10:45] vedad@kajtaz.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:07:28] 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 21:32:31] vedad@kajtaz.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... :( ------------------------------------------------------------------------ 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/15801 -- Edit this bug report at http://bugs.php.net/?id=15801&edit=1