Hi Yasuo, On 26 February 2015 at 08:51, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > >> This can be prevented by restricting phar archive name or forbid all >> URI name at all. The latter is better choice. > > If by "all uri" you mean all streams, that would be very high burden, > which may break many applications using streams, including phar handling. > >> There is design problem obviously. The reason why phar:// is allowed is >> that "allow_url_include" is not INI_ALL. > > The reason why phar is allowed is because phar is not a remote stream, > so access to phar is the same as access to local file system, which is > necessary for include anyway. The contents of phar is in the same domain > as contents of local filesystem, that's why no distinction is made. >
Agreeing with Stanislav on this one. While it may appear attractive to limit the phar: protocol, it's a fairly vital extension of the filesystem that we should be wary of tampering with. It would probably be more productive to clarify the status of phar: URLs in the docs for allow_url_include, if only to emphasise that it's not covered by that setting. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
