[sugar] DOS via D-Bus

[Bert Freudenberg]

Hi folks,

the Bitfrost spec only touches briefly on D-Bus. So I was  
wondering ... At the very simplest, an activity could ignore the quit  
message sent from the frame - is it going to get killed after a  
timeout? Or, it could flood the D-Bus with a lot of messages.

So, are there general mechanisms in place to defend against this? As  
I understand it, sharing "active documents" which contain code are  
explicitly encouraged in the educational vision of the project. Or  
does an activity that allows "active" documents have to provide their  
own sandbox to try to minimize what the code could do? Like, if we  
made D-Bus accessible to JavaScript in the browser, would that be a  
Bad Thing? If we allowed Python as a scripting language in the  
browser? Which I would find immensely cool.

The problem at hand for me is that we wanted to switch etoys to  
handle d-bus itself for quite some time. This would, for example, get  
rid of the Python wrapper which would free up some valuable system  
resource. A few months ago everybody thought this was a good idea,  
and actually encouraged to develop a non-Python activity, if only to  
make sure the protocol used really is independent of the  
implementation language.

However, this would potentially give direct d-bus access to every  
etoy. I think it would not be worse than sharing a Python activity  
that could cause havoc on the d-bus easily. But I'd like to hear  
other's opinions on that.

- Bert -