Please troll, do you go away if I close my eyes?
--Jani
On Wed, 29 Jun 2005, Russell Nelson wrote:
Rasmus Lerdorf writes:
> Russell Nelson wrote:
> > When the top Google result for 'php security flaw' returns
> > mysql_query() instead of include(), I will agree that you are correct.
>
Gareth Ardron writes:
> You absolutely can't trust any input whatsoever and it must be
> validated.
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells sup
Nicolas Bérard Nault writes:
> If a programmer is not capable of controlling an user input,
You are making a mistake here. You are assuming that the user
realized that 'include' is really 'includeremotesecurityhole'.
Consider the security implications of a user 'include'ing a file that
doesn't
Russell Nelson wrote:
> There is no problems with the include() statement. The only thing
> missing, is a tag in the docs ;)
If there were no problems, then why would a tag be needed?
He's trying to say, as I was - that the include() function works as
expected and is just fine as is but /ma
Rasmus Lerdorf writes:
> Russell Nelson wrote:
> > When the top Google result for 'php security flaw' returns
> > mysql_query() instead of include(), I will agree that you are correct.
>
> I am not sure a Google search is a very good barometer here.
> ... today it really doesn't seem like it
Olivier Hill writes:
> Are you suggesting that someone could wipe out your entire machine by
> passing a remote script that would system('rm -rf /');?
It would "only" delete every file owned by the user that the webserver
runs as. On my server, that's 1846 files, some of which I'm fairly
attach
Russell Nelson wrote:
Now, don't tell me that it's not insecure. Everyone here realizes
(and I know this because they've told me) that programmers who are
concerned about security will always check the values passed into
'include'. Why would they need to do that if 'include' wasn't
insecure?
Just for the records, I guess you all know that I meant 'language
construct' where I wrote 'function' instead (in reference to include).
On 6/29/05, Nicolas Bérard Nault <[EMAIL PROTECTED]> wrote:
> PHP is not, in my opinion, idiot-proof. You're right on that point.
> Where our opinions differ is
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is about what should be done about this.
If a programmer is not capable of controlling an user input, why then
should we trust him with anything ? A lot of other functions taking
user input as arguments c
Russell Nelson wrote:
> I think the documentation quite clearly states that /all/ functions that
> deal with files may deal with remote files if the fopen wrappers are
> enabled
Why did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that "the d
Russell Nelson wrote:
> Stefan Esser writes:
> > I agree with Rasmus. Remote URL Includes are dieing out.
>
> That's not what Rasmus said.
>
> > Most released advisories are SQL Injections nowadays and well maybe
> > Russells next mail says: mysql_query() considered harmful.
>
> When the top
Gareth Ardron writes:
> To me, it's obvious that include includes a file - I see no obvious
> determination that that file is either local or remote in the "include"
> statement.
Can you name some other languages in which 'include' has such
incredibly sharp edges? C? Python? Perl? BASH? Sed?
On 6/28/05, Russell Nelson <[EMAIL PROTECTED]> wrote:
>
> If you have to read the man page to find out that 'include' will let
> some random user from a third-world country execute 'rm -rf /' on your
> server, then I propose that the problem is not that users didn't read
> the man page. The probl
Mike Robinson writes:
> Uh, no. Affordances are
Okay, I'm wrong about that. I don't need to push that analogy to make
my point.
> You don't save people by filing down the sharp edges on a tool. You
> do it by telling them it's sharp.
If you look at a tool, you can tell if it's sharp. If yo
Quoted Text:
In other words, it can only be used to include files at or below the
current directory.
This is counter productive, it is a horrible idea to store include
files within (/below) the document root, if you're going to suggest
strange sweeping changes go the reverse direction, ensure that
Russell Nelson wrote:
Graphical user interface designers understand the idea of an
'affordance'. An affordance is something whose operation is obvious
simply by looking at it. An uparrow button moves something upwards.
'include' is an affordance. It obviously includes a local file.
To me,
Russell Nelson wrote:
> Graphical user interface designers understand the idea of an
> 'affordance'. An affordance is something whose operation is
> obvious simply by looking at it. An uparrow button moves
> something upwards.
Uh, no. Affordances are the range of possible actions by a user, p
Al Baker writes:
> Turning PHP into a babysitter
Nothing you wrote explains why so many people have had this problem.
Everything you write is an attempt to deny that the problem exists,
deny that serious programmers have the problem, deny that the problem
is due to a badly designed intrinsic, and
Can you please send the patch?
If it got stripped, then maybe post a URL.
Thanks.
At 01:49 PM 6/24/2005 -0700, Andrew Prendergast wrote:
Just to add, with the patch one can set PHP_FCGI_MAX_REQUESTS quite high,
which will give a big reqs/sec performance boost, eg:
PHP_FCGI_CHILDREN=10
PHP_FCGI
This yet again illustrates the sillyness of autoload, if we are going to
have a feature that autoloads classes it should be explicit in it's
usage:
autoload("Class_Name");
defaults to loading Class_Name.php ?
if __autoload exists, it calls that..
adding all sorts of magic to the Class operators
I think it means being able to scope the default execution block for a
script. Normally script goes from top-to-bottom dipping into each
include and compiles and executes them in a linear fashion.
Perhaps having a main would hold off on the execution part until you got
to the main() and from ther
There is nothing wrong with fopen or include, and PHP isn't
instrinically broken here. The only thing intrinsic about PHP that has
anything to do with these security areas is how PHP is powerfully simple
- lowering the bar for adoption. When you do this, you pick up newbie
programmers who code up
For example...
--- example.php ---
--- end example.php ---
`php -q example.php` would output "Hello World!"
With this you could potentially eliminate the global scope if you
chose to. For the record, by no means do I want PHP to be Java. I just
think this feature would be a nice finishing touch
What do you mean by the script being a class ?
On 6/28/05, Jesse Binam <[EMAIL PROTECTED]> wrote:
> Any thoughts on the idea of a magic method called "__main()" or
> "__exec()" that would be called if the script being executed is a
> class.
>
> --
> PHP Internals - PHP Runtime Development Mailing
Hi James,
On Tuesday 28 June 2005 23:32, James Crumpton wrote:
> function __autoload($name) {
> require_once($name);
> }
> I just don't understand the logic behind throwing a fatal error when I'm
> writing code to try and prevent one from occurring.
You should add error checking to your
I opened a bug (http://bugs.php.net/bug.php?id=33459) to report an issue with
the default behavior of class_exists calling __autoload in PHP5. The bug was
marked as bogus, and basically stated that it's PEARs problem. After responding,
the bug can now longer be searched for.
I believe this still
Derick,
I did a quick build without the date extension and php5ts.dll dropped
296kb. I did some additional digging. Some of the additional is
because of the new PDO object, and some becuase PCRElib doubled in
size. But the object file that really jumped in size was
zend_execute.obj: from 271kb
Sorry - that was a typo. It is already named php5ts.dll.
Michael
> Should it be named php4ts?
>
> Andrey
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
PHP Internals - PHP Runtime Dev
At 01:26 AM 6/28/2005, Andrey Hristov wrote:
>Should it be named php4ts?
ewww - certainly not. Win32 has no problem with loading two modules,
e.g. php4ts and php5ts, mod_php4 and mod_php5 all in the same process.
But not if the dll names collide.
At 09:56 AM 6/28/2005, Wez Furlong wrote:
>If th
It does things differently; it compiles the DLLs to run at a
particular base address; provided every DLL is compiled at a different
base, then it can be mapped directly into the right memory space. If
there are overlaps between the compiled bases, then the loader can
relocate DLLs until it figures
Any thoughts on the idea of a magic method called "__main()" or
"__exec()" that would be called if the script being executed is a
class.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 28 Jun 2005, Wez Furlong wrote:
> It doesn't hurt anything; in fact, a single big DLL is more resource
> efficient than a number of smaller DLLs on win32, as the kernel
> doesn't need to spend as much time relocating the DLLs.
Jus twondering... windows has no non-pic thing?
Derick
--
De
It doesn't hurt anything; in fact, a single big DLL is more resource
efficient than a number of smaller DLLs on win32, as the kernel
doesn't need to spend as much time relocating the DLLs.
--Wez.
On 6/27/05, DvDmanDT <[EMAIL PROTECTED]> wrote:
> Should those really be built into php4ts.dll?
>
>
translation the PEAR documentation into Chinese.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stefan Esser writes:
> I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
> Most released advisories are SQL Injections nowadays and well maybe
> Russells next mail says: mysql_query() considered harmful.
When the top Google result for 'php security flaw' re
Rasmus Lerdorf writes:
> How is this any different from
>
> include "../../../../../etc/passwd";
That doesn't let you execute hostile content with local privs.
> There are a lot of places where unfiltered user input can cause some
> rather severe problems.
I agree! And yet there is p
> If the very first thing you have to do with a language feature is make
> sure that it doesn't function as designed (which is to execute hostile
> content with local privileges), then clearly the design of that
> feature is wrong.
Or the default value of the configuration setting has been a bad c
On Wed, 15 Jun 2005, Moriyoshi Koizumi wrote:
> Hello,
>
> On 2005/06/14, at 21:59, Derick Rethans wrote:
>
> > The following test is failing for everybody. This bug occurred after you
> > fixed the bug in report #29493. Can you please have a look at it, and
> > perhaps revert it - as it seems t
38 matches
Mail list logo
