Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82024 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92693 invoked from network); 6 Feb 2015 08:30:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2015 08:30:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:45834] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/19-45146-A9B74D45 for ; Fri, 06 Feb 2015 03:30:19 -0500 Received: (qmail 31783 invoked by uid 89); 6 Feb 2015 08:30:15 -0000 Received: by simscan 1.3.1 ppid: 31777, pid: 31780, t: 0.0871s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 6 Feb 2015 08:30:15 -0000 Message-ID: <54D47B97.2080204@lsces.co.uk> Date: Fri, 06 Feb 2015 08:30:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once() From: lester@lsces.co.uk (Lester Caine) On 06/02/15 05:01, Yasuo Ohgaki wrote: >> But it is the key point. It is not PHP role to do it. PHP is not >> > alone. It is a server configuration job. But I have said that already >> > many times, we got our points :) > I understand your point. > > We need both OS and PHP feature for perfection. Both of them are required. > > Current PHP just reads & executes all accessible files by include. > I think you understand my point, too :) The question is essentially CAN one prevent PHP on it's own from running things it shouldn't. In order to prevent people who do not understand the security risks from 'making a mistake'. The answer is probably only yes for a distribution that only comes from PHP. Other distributions are not following guidelines now so expecting them to do in the future is questionable? This is more about education of the whole infrastructure but I don't see the point of yet another load mechanism? I thought we had introduced all the necessary restrictions on include and require already? From a 'nannying' point of view I would have thought it was that hole which needed plugging since the people you are trying to protect will not use a new mechanism anyway? I hope that I have my own installations configured such that one can't upload material on-line that can be accessed but having to ensure third party libraries are using 'script' rather than 'include/require' seems a little problematic ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk