[development] Remove PHP filter by default

[Bèr Kessels]

Op zondag 29 januari 2006 18:18, schreef Karoly Negyesi:
> The problem is in restriction. Folks, understand this: as long as PHP  
> filter is there, all you need is one broken contrib module and your site  
> is dust. Also, I know that many shops won't even consider Drupal for this  
> filter because it's too risky. If you need to say "no it's not because"  
> then you have lost the argument because if you need to reason then it's  
> not secure enough. (And yes, input filtering is also needed but let's  
> leave something for the spring, too :) ).

The very fact that the input filter is there, is what bothers me most. Yes, it 
can be restricted. It can be turned off. But you need to know about all the 
ways to get there. 

We have investigated the ways to become SU. in drupal 4.7 there are at least 7 
totally different ways of rooting (for becoming SU is that, exactly) a drupal 
site. Nearly all are related to gaining PHP rights, then using that to change 
the PW of SU. 
So in order to be completely secure, you have to:
 * turn off "administer user" rigths (unreated to PHP filters)
 * give no-one administer permissions. resulting in not allowing half of the 
modules to be switched on-off, rendering flexinode (for example) unusable and 
more. (we really need to find some way to cascade this, so that a users can 
never give anyone more rights then he has)
 *  give no-one "administer input filters" rights (very unhandy if you want 
ppl to control wiki syntax or so)

Or, in other words: to maintain a secure network of sites, you must configure 
them to be hardly unusable, because you need to turn off a lot of crucial 
features. PHP input is the biggest contributor of all this. 

So, if we want Drupal to be the hosting tool, developers tool and JoeSchmoe 
tool, we really need to chop out a lot of functionality and stick that into 
modules that can be removed. Because a non-existing module is nothing to 
worry about. Developers should (IMO) not even consider using php input, they 
should deliver it with acme_inc_custom_code.module (or so).hosting providers 
will want to be 500% sure that no-one can run arbitrary code. Never. And Joe 
User wants to copy-paste. Only for the latter the PHP input is really needed. 

Also note (unrealted, but certainly worth thinking abuot) that Rasmus pointed 
uot that eval'd code performs worse and uses more memory.

And that did not even get me started about the upgrade hell when you have a 
lot of b0rken PHP input (no longer existing API calls) making your site 
inaccesible.

All in all, it boils down to: Drupal is fine to ship with all the PHP input 
stuff, but it must be able to get rid off it. Completely. We need to work on 
that. 

Bèr
-- 
 PGP ber at webschuur.com
  http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
 PGP berkessels at gmx.net
  http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc