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. On Fri, May 19, 2017 at 9:31 PM, Aldrin Leal <ald...@leal.eng.br> wrote: > 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 > > On Thu, May 18, 2017 at 11:19 PM, voidlogic <voidlog...@gmail.com> wrote: > >> 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. >> >> On Thursday, May 18, 2017 at 3:25:49 AM UTC-7, Aldrin Leal wrote: >>> >>> 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 >>> >>> On Wed, May 17, 2017 at 11:55 PM, voidlogic <voidl...@gmail.com> wrote: >>> >>>> 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. >>>> >>>> On Wednesday, May 17, 2017 at 5:20:34 PM UTC-7, Aldrin Leal wrote: >>>>> >>>>> go-plugin wouldn't work? >>>>> >>>>> github.com/hashicorp/go-plugin >>>>> >>>>> >>>>> -- >>>>> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal >>>>> >>>>> On Wed, May 17, 2017 at 7:05 PM, voidlogic <voidl...@gmail.com> wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> -- >>>>>> 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...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> 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...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
