Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64679
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6LxSccSnJ-0qu87srT80B+dWAWVApGCLa=D1UCDmiNCg@mail.gmail.com>
References: <CAOg_pRTGK5P18W_=fmdgGUNBfV6gRuTZg3xQsbH4+qBKk9teBQ@mail.gmail.com>
	<CAEZPtU66sACosd9ThxNkhVYW+fVkSBB5VZDeAGJ+0Zb9uUjSQQ@mail.gmail.com>
	<CAH-PCH5Wm=BGwe3mwoZ1t8E2LQoqJgiHKCz4chXVO=ChP6VKrw@mail.gmail.com>
	<CAEZPtU6LxSccSnJ-0qu87srT80B+dWAWVApGCLa=D1UCDmiNCg@mail.gmail.com>
Date: Tue, 8 Jan 2013 14:24:31 +0100
Message-ID: <CAOg_pRTtFDC7aWJZH-jc5a_NfL95jrY4_wv6=bJsDjC+ase-Wg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442838aacf9e804d2c6ddf0
Subject: Re: [PHP-DEV] File-Paths exceeding MAX_PATH on Windows
From: nicolai.scheer@gmail.com (Nicolai Scheer)

--f46d0442838aacf9e804d2c6ddf0
Content-Type: text/plain; charset=UTF-8

Hi!

On 8 January 2013 06:48, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs <tyra3l@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

--f46d0442838aacf9e804d2c6ddf0--