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@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc