File-Paths exceeding MAX_PATH on Windows

2013.01.08. 6:48, "Pierre Joye" pierre.php@gmail.com ezt írta:

hi,

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).

A better solution I work on for previous php version (incl. 5.5 as I
won't make it in time) is an extension which would override existing
functions. Next major version (6) will support unicode filenames,
which will solve the 255 chars horrible limitation.

by 6.0 you mean php next after 5.5, or adding this to the core would
require
a major version for some reason?

I mean 6 as the changes are rather big. It could be possible in 5.6
but I rather prefer to target the next major.

thanks for the clarification.

Hi!

hi,

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