Re: File-Paths exceeding MAX_PATH on Windows

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