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