Holy flying crapload!
If you want to protect data from mass deletion or defacement, you need an architecture which
gives you that protection. In other words, some sort of RPC interface (doesn't *have* to be
XMLRPC :-) instead of direct SQL access.
There's simply no other way to do this safely. And I haven't even started on PHP and its
security model, which is woefully inadequate for a task like this, no matter what you do. (So
is that of every other common programming language, except possibly Java. Maybe. If you're
lucky, disable stuff like introspection, etc. etc.)
It should surprise nobody that if you have that, you can just offer (suitably protected)
access to *that* to anybody who'd like to run a modified version of your server, instead of
letting people run their code on yours (which has its own security problems).
Posted Nov 29, 2007 14:44 UTC (Thu) by sepreece (subscriber, #19270)
[Link]
Hmm.
Maybe you could do a copy-on-write approach to the site's data. When you forked the source,
your copy of the source would also get a "virtual fork" of the site's data that would just use
the site's original data until you changed something, then the change would stay local to the
version that was visible to your fork of the software.
I agree with smurf that the idea of letting people fork the software but use it to modify the
site's data directly is unmanageably permissive. Linus doesn't let you directly modify his
tree...
Freeing web services with Forkolator
Posted Nov 29, 2007 19:56 UTC (Thu) by smurf (subscriber, #17840)
[Link]
Copy-on-write sounds like a good idea, except that (a) you'd need database support for it, (b)
you still have the "anybody could read everybody's personal data and crack their passwords"
problem.
Freeing web services with Forkolator
Posted Nov 30, 2007 1:33 UTC (Fri) by sepreece (subscriber, #19270)
[Link]
Sure - I was assuming access controls would still be in place for private data and only
talking about an approach to allowing software forks to work on communal sites.