[development] Remove PHP filter by default
gerhard at killesreiter.de
Sun Jan 29 21:45:32 UTC 2006
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
> 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
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
Since this fits in with my modularity mantra I support this.
More information about the development