ID: 32851
Comment by: webworkings at gmail dot com
Reported By: stegelmann at rz dot rwth-aachen dot de
Status: No Feedback
Bug Type: Safe Mode/open_basedir
Operating System: SunOS 5.8
PHP Version: 5.0.4, 4.3.11
New Comment:
I was very impressed about opportunity to work from home and I register
to website work-home.org now i have lots of offers to work from home..
I am very thankful my friend who told me about this website. I quit my
job and I am working from home only. I am very happy being of my
family together all the time ;) Did you hear something about that? Maybe
You know something about that too?
Previous Comments:
------------------------------------------------------------------------
[2005-09-29 16:25:40] ajakum at inode dot at
I suppose the problem lies with the fact that symlinks in open_basedir
are getting resolved, while symlinks in fopen-calls aren't.
For example, we have open_basedir /home/bla:/home2/bla and symlink
/home/bla -> /home2/bla.
The following fopen calls fails:
fopen("/home/bla/foobar","w");
since the open_basedir virtually gets resolved to /home2/bla:/home2/bla
(as documented in the php docs). What is not documented and I still
think is a bug (even after reading #32851, #31309 and some not very
friendly comment by tony2001 in #30188) is the fact that the symlink
within the directory of the destination path is not getting resolved.
One can not use any path within "/home/bla" for file creating (or
upload moving) as the open_basedir values have their symlinks resolved
while the destination files haven't.
We solved it by symlinking a subdirectory of /home/bla to /home2/bla
and using that one, as this solution doesn't use a symlinked path in the
open_basedir setting which would get resolved.
I still think it should be possible to set an open_basedir restriction
to a symlink without running into the above-mentioned problem, e.g. by
also resolving the symlink in the destination filenames.
This has been verified with php4-STABLE-200509291243 and by looking at
the source of php5-STABLE-200509291239.
------------------------------------------------------------------------
[2005-07-12 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2005-07-04 01:05:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
------------------------------------------------------------------------
[2005-04-28 00:06:15] stegelmann at rz dot rwth-aachen dot de
I've read the documentation. At the risk of repeating myself:
If the symlink was resolved - I would expect at least one of the given
open_basedirs to match (as both possibilities are specified - resolved
and unresolved).
If this is not the intended way it should work, why is there a
difference between creating a new and opening an existing file (as
opening an existing file in the symlinked directory works, while
creating a new file fails)?
------------------------------------------------------------------------
[2005-04-27 23:28:23] [EMAIL PROTECTED]
This is expected behaviour and it's documented in the docs:
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink."
http://www.php.net/manual/en/features.safe-mode.php
Pay attentions to the last sentence.
------------------------------------------------------------------------
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/32851
--
Edit this bug report at http://bugs.php.net/?id=32851&edit=1
