Secure Python

[Paul Boddie]

timmy wrote:
> Paul Boddie wrote:
> > Diez B. Roggisch wrote:

[Re-adding material...]

> >>At least to me - and I presume pretty much everybody except you in this
> >>thread - this means that he is interested in executing arbitrary pieces of
> >>python code inside the interpreter, which comes from e.g. players who
> >>customize their in-game behavior of their avatars.

Here is where the issue of sandboxing is indirectly introduced into the
discussion.

> >>Now how exactly does linux (or any other resource limiting technique on any
> >>OS) help here - killing the whole game server surely isn't a desirable
> >>solution when one player goes berserk, might it be intentionally or not.
>
> > And this is where the hot topics collide: people want performant
> > multitasking with lots of shared state (the global interpreter lock
> > controversy) together with sandboxing so that the individual threads
> > can't access most of that shared state (the restricted execution
> > controversy).
>
> i'm not talking about sandboxing, that's a whole different kettle of
> fish. i'm talking about resource managment options you can set in for
> instance, the linux kernel.

Yes, I know. I was merely covering related concepts of relevance
introduced earlier in the discussion (see above). In any case, if you
only have control over resource limits on execution contexts at the
operating system process level, yet your server architecture is
entirely based on a single process with many (micro)threads, then
you've got to consider the problem of restricting their
behaviour/consumption using the facilities available to you, most
likely by considering other server architectures. This, I argue, is
perfectly reasonable in order to solve both issues being discussed
using operating system facilities.

> you can limit the cpu and memory a process uses while still allowing it
> the same access it would have outside of a sandbox. that way if any
> clever monkeys try to dos you they merely consume their alloted quota.

Indeed.

Paul