[PLUG] Preventing Probes Like This

Ronald Chmara ronabop at gmail.com
Tue Aug 26 10:04:32 UTC 2008


On Aug 25, 2008, at 3:56 PM, Eric Wilhelm wrote:

> # from Ron Chmara
> # on Monday 25 August 2008 14:59:
>
>> Of course, the counter argument to making this easy is noted in this
>> very thread, as PHP was allowed to easily read /etc/passwd (it's a
>> file on the hard disk, why shouldn't PHP be able to read it?...), and
>> yet, there was an implied expectation that PHP "shouldn't be able to
>> do that".
>
> That's not really it.  If you do open(my $fh, '<', '/etc/passwd'), you
> get that.  If you're just trying to display some bit of text that's
> supposed to be next to you in the webroot, your tool (especially a  
> very
> web-centric tool) should give you a default way to do that which  
> limits
> the filenames to within the webroot.

If your webroot for the application is /etc/, because your particular  
application is a sysadmin application, /etc/passwd being read- 
accessible makes perfect sense.

There are many good arguments for many different PHP behaviors. :)


>  The framework should give you convenient tools for doing
> the sensible thing.  It can still give you plenty of rope, but handing
> me a neatly coiled rope is completely different from handing me a
> bucket full of knots.

You somewhat lost me, but I would guess that the general debate  
focuses on the issue of whether PHP/perl/python/C/java/bash/ 
<whatever> should be limited to being a jailed "DocumentRoot"  
language, or a language that can inherit the permissions of a parent  
process.

Perhaps part of the "mental problem" is that people who deployed PHP  
on their servers did not realize how much power it had. This is not a  
new mistake, just an old one, repeated. If users should not be  
allowed C/bash/perl level scripting, then, well, shut off PHP?

-Bop



More information about the PLUG mailing list