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