Gregory Maxwell wrote:
So— Any thoughts on how you address the universal problem of the DOS attack script?
[snip]
I'm of the impression that simply setting a limits on CPU and memory isn't sufficient to address this, because the reasonable limit will be high enough to be dangerous when the object is added to 100k pages, while a limit low enough to be safe everywhere will be far too constraining and likely to fail at random depending on overall system load.
It's never an easy problem. :)
But there are some interesting potential things to poke at, such as having per-template limits, per-cluster limits, etc -- we could in theory shut down some template rendering while still spitting out the rest of a page on a timely basis.
Disadvantage: Like PHP, Python is difficult to lock down securely.
I don't know that difficult is really the right description here. People willing to spend far more effort on this than you probably are have tried to sandbox python and failed. I don't believe there is any real production grade support for the level of lockdown required for either PHP or Python. And I'd worry that any PHP implementations of the sandboxed languages might lose the battle tested sandboxing.
It's acceptable for mediawiki to fall back to lower performing alternatives when c modules can't be used, but I doubt its acceptable to fall back to less secure ones!
Indeed. :)
Is execution in enviroments where c modules are not possible actually a hard requirement? If it is I think this is a non-starter.
Since requiring custom PHP modules would pretty much rule out all casual third-party use of MediaWiki, that would definitely be a hard requirement to not require it. :)
I'd really _like_ to be able to avoid having to require external executables either, if it can be managed, but that's harder since it means having a pure PHP implementation of the scripting language. (ouch!)
-- brion