Hi!
On 8 January 2013 06:48, Pierre Joye <pierre....@gmail.com> wrote:
> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
> > is this about allowing the user to shot him/herself in the foot, or
> adding
> > this feature could potentially break some existing functionality (eg. new
> > trick to bypass open_basedir, etc.)?
>
> All of them, as the paths are passed right to the kernel APIs, without
> any system checks like in the higher level APIs (posix or win32).
>
I justed checked that without any modification the userspace functions
unlink()
mkdir()
rmdir()
rename()
do work with "\\?\" prefixed paths, because there is no call to
expand_filepath() i.e. paths are passed directly.
So the only function we needed to modify is php_plain_files_stream_opener...
What do you think about adding:
zval **ctx_opt = NULL;
...
// basedir checks
...
if (context) {
if ( SUCCESS == php_stream_context_get_option(context, "file",
"assume_realpath", &ctx_opt) && Z_TYPE_PP(ctx_opt) == IS_BOOL &&
Z_LVAL_PP(ctx_opt) == 1) {
options = options | STREAM_ASSUME_REALPATH;
}
}
Usually STREAM_ASSUME_REALPATH is set by _php_stream_open_wrapper_ex when
USE_PATH is set and the path was resolved successfully. Unfortunately, the
following zend_resolve_path fails as before, because of the '?' in the path.
With the context option above, I could do the following:
<?php
$path = "\\\\?\\y:\\dummy_folder\\dummy.txt";
$options = array( "file" => array( "assume_realpath" => true ) );
$ctx = stream_context_create( $options );
$fh = fopen( $path, "r", false, $ctx );
Which works without the need to touch MAXPATHLEN by just using the already
implemented skip of expand_filepath().
Don't get me wrong, I'm not trying to bend php to allow the usage of this
ugly workaround. But as this is quite well documented, and supported on
windows, I just like to ask if adding the above context option is a
feasable way to prevent php with interfering with the prefix.
As of now, there don't seem to be any stream context options for file://.
Question here is, if it is ok to expose a stream option telling php "do not
interfere with my paths, I'm doing this myself". To my mind, since it
already works for anything not involving php_plain_files_stream_opener,
this could be ok.
There are already a lot of stream context options for other wrappers. And
most of them do very lowlevel adjustments...
Yes, there are better ways of doing this, but these future implementations
will take a lot of time and will not be available within the next months.
Of course I'm trying to prevent finding myself compiling php for production
use incorporating just such a little change...
I currently don't see a way how I could introduce the mentioned context
option inside an extension without duplicating a lot of code. Any pointers
are welcome...
What do you think?
Greeting
Nico
