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. > Script cannot change the setting, therefore special phar:// is needed to > be allowed unconditionally. I would say INI_SYSTEM for allow_url_include > is false sense of security. It introduced security issue like you've > mentioned. It doesn't introduce any issues, unless you declare there should be distinction between files on the filesystem, which is needed to make your approach useful. But I do not think it's a good security - trying to allow including user-controlled files securely is IMO a futile task. The problem should be fixed at the root - by not having such includes that allow arbitrary filenames injected by user. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
