Callback Functions at Verse Server and Custom Commands about verse HOT 3 OPEN

Probably outside of the scope, but I'm imagining this looking like FUSE.

Maybe you could have plugins live in the verse tree proper, written in python, using the pypy-c-sandbox for fast/secure execution. Would make writing plugins a bit of a pain, since most of the pip libraries wouldn't be available, but it would be fast and users could upload the code into the verse tree itself, and have users upload custom plugins. Pypy-c-sandbox keeps it all safe, and let's you limit users plugin's ram and cpu time.

Of course the pypy-c-sandbox is not a huge focus at pypy. It only works on *nix, takes a while to compile, and is generally poorly documented. Still, plenty of servers only run on *nix. As long as the client libraries could run on other platforms eventually I don't think it would be a real problem.

from verse.

Your proposal have only small benefit, but it brings unnecessary security risks. I guess that developers writing plugins will be smart enough to run their own verse server.

from verse.

Ehh, maybe we're imagining different use cases. I'm picturing verse as being the "kernel" for a sort of plan9-esque (everything is a file) operating system. Well plan9 and gnu/hurd, they both had good features.

I see it as a medium benifit a long long time from now, and a pretty minimal security risk.

FUSE style systems are a fundamental part of the hurd system architecture, and lettings users set up those filesystems is important. I guess you imagine it being more of a "connect to a server, run a particular set of apps" thing? Like the current web browser paradigm, but with more ability for users to co-operate on tasks.

Keep in mind that the web stack was never supposed to be doing most of the stuff it does. A web app would have been a foreign concept not too long ago. Hell, web browsers have replaced the operating system as the main thing people/programmers interact with a lot of the time. Scope creep happens, and eventually verse will be filling the shoes of an OS, just like web browsers do. Try to make it a good OS, and use operating system design principles.

Anyway, along with my ranting about operating system design, which offers a tenous benifit at best, I don't think that pypy-c-sandbox is much of a security risk.

The pypy-c-sandbox isn't the normal attempt at python sandboxing, which tries to do it at a program level. This is a compiler level change.

PyPy offers sandboxing at a level similar to OS-level sandboxing (e.g. SECCOMP on Linux), but implemented in a fully portable way. To use it, a (regular, trusted) program launches a subprocess that is a special sandboxed version of PyPy. This subprocess can run arbitrary untrusted Python code, but all its input/output is serialized to a stdin/stdout pipe instead of being directly performed. The outer process reads the pipe and decides which commands are allowed or not (sandboxing), or even reinterprets them differently (virtualization). A potential attacker can have arbitrary code run in the subprocess, but cannot actually do any input/output not controlled by the outer process. Additional barriers are put to limit the amount of RAM and CPU time used.

It should be as secure as the containing proccess, since the pypy doesn't allow your code to do any syscalls.

I think that verse is ultimately a better way of doing things then either the file systems of most operating systems, or the DOM of web browers. So what you decide now could have repurcussiosn, if verse is widely successful.

But depending on how your plugin architecture ends up working, it should be something that anyone could implement. I definitely think it's something you'd need to implment in parts, with basic non-sandboxed python callbacks first, and then extending that to user callbacks somewhere down the line.

As an aside, I'm not a fan of custom commands as a kernel level feature, but like you say, it's easy to critisize other people's system architecture.

from verse.