Re: [RFC][DISCUSSION] Introduce scrpt_path

Hi Matthew, On Sat, Feb 7, 2015 at 1:45 AM, Matthew Leverton <leverton@gmail.com> wrote: > On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > https://wiki.php.net/rfc/script_path > > > > It's work in progress, but I would like to start discuss. > > > > I don't really like it; but I don't really like most INI-based solutions. > One possible alternative is use of parser state and use only upload_path. This way, we can remove one INI. > > I agree that this is a problem with poorly written code, but at the > same time I don't know that a good solution is to compensate in this > regard. Bad programmers will always be bad programmers. Now we're > giving them a crutch that almost encourages unchecked includes by > relying on an INI configuration. What happens if you are using > multiple libraries and they are each overriding their (and your) > settings? It just feels messy. > Basically, it's administrative solution. Application should set these setting or administrator should. Library shouldn't touch the setting, otherwise they hit their own foot. > > The same thing could be accomplished config-less with a callback > system that is triggered on script includes (if any callback returns > false, an error is thrown), but I think I'd dislike that for similar > reasons. If upload path is located under docroot, we must use per dir INI and set engine=off This requires administrative task (or Apache should enable .htaccess) Unlike upload_path, this couldn't prevent PHP from loading like require('../../upload/evilfile'); Since my goal is to make PHP as secure as other languages, this case may be ignored. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net