[development] Remove PHP filter by default

[Gerhard Killesreiter]

Bèr Kessels wrote:

>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've had that input filter for at least since Drupal 3.0 and probably 
even before that. All of a sudden you are worried about it?

>We have investigated the ways to become SU. in drupal 4.7 there are at least 7 
>totally different ways of rooting 
>

Please don't use unrelated terms to describe this problem.

>(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 what? I could probably delete Dries' account on drupal.org. I've 
never done it and probably won't do it.

>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 trust the people you give administration rights...

>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.
>

It really amuses me that you bring up this discussion /after/ you've 
started a hosting service. :p

I am fine with putting this in a module, btw. But this is mainly because 
I believe in modularity. Today I've written three og contrib modules. 
Each of them provides some small functionality I need. I could have 
merged them into one big thing, but I think that the modular approach is 
better suited to Drupal and will also other people use these modules 
independendly.

> 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.
>

They just need to figure out how to secure their apache setup. Not that 
a big deal.

> And Joe 
>User wants to copy-paste. Only for the latter the PHP input is really needed. 
>  
>

Well, these are the people who'd probably want to become your clients. 
So I think it is not the correct approach to take this away from them.

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

He also said that unserializing stuff would eat a lot of 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.
>  
>

Right, that is the main reason why I think that using php input is a bad 
idea after all.
That and the fact that browser windows aren't made for editing code.

>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. 
>  
>

Since this fits in with my modularity mantra I support this.

Cheers,
    Gerhard