Compiling Go plugins with playground/NACL/GAE-like isolation

[voidlogic]

Hey Everyone,

I'm working on a project to allow other teams within my company to submit plugins that are executing as optional event handlers within my application. We currently support Lua but with the addition of Go plugin support we would like to support Go as well (our app is written in Go itself).

The new plugin package looks like it will work well: https://golang.org/pkg/plugin/

The only caveat is it would be nice to have the plugins have similar filesystem, unsafe, etc isolation that the playground has. One idea would be to try to maintain a fork of Go that allows these GOOS=nacl mockups to be enabled for amd64 plugins- would that work or does a plugin share a runtime with the loading application? I don't think pure NACL with work without linking the NACL loader into the application...

How does Google's app engines isolation work? A forked Go runtime? With the difference that no part of the app needs privileges (unlike here were the app doing the loading should be privileged)

If anyone has thoughts on loading plugins with some isolation, I would love to hear them. Thanks!

-Tylor

[Aldrin Leal]

go-plugin wouldn't work?

github.com/hashicorp/go-plugin

--
-- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[voidlogic]

For some use cases I am sure this kind of integration would be just fine. But if functions within plugins are called often enough the overhead difference between calling a function in a dynamically linked library (.so) and communicating via a UNIX socket will quickly become non-trivial. Even if you move from pipe based IPC to shared memory this is still a large gap as compared to direct calls.

For my use case, I may have resort to having users submit source code that my system then compiles (to .so) and vets (so I can black list packages, etc) if I can't find a better method of isolation.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Aldrin Leal]

what if go-plugin + docker? I think you could block networking altogether. Wiring those two wouldn't be a problem if you use things such as go-dockerclient

--
-- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[voidlogic]

As I mentioned before go-plugin uses RPC/IPC which is much slower than shared/dynamically linked libraries.... So if you didn't have a high performance use case, that would probably work.

[Aldrin Leal]

so its not possible. It seems you'd need to pick to have between either:

a. a fast ipc mechanism (shmem, shared/dynamic libraries)

b. sandbox isolation

c. performance

d. Deep Kernel Hacking

http://stackoverflow.com/questions/27417561/linux-is-it-possible-to-sandbox-shared-library-code

--
-- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Tylor]

In my case, since I can have my users submit their code to my service and I take care of the building and distributing and loading their plug-in, I'm going to force them to:

1. Only import from a whitelisted set of packages

2. Forbid them from calling go

3. Disallow cgo

4. Have their interfacing functions/event handlers have passing unit tests and pass my generic integration unit tests

Since my users are other teams within the same organization, while not ideal, that should balance the safety and performance concerns. This has been my backup plan all along, I was just hoping someone would tell me there was a way to enable GOOS=nacl isolation code paths in the stdlib/runtime while building amd64 plugins. Or something similar.