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 f
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
--
-- Aldr
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 yo
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, / http://about.me/aldrinleal
On Wed, May 17, 2017 at 11:55 PM, voidlogic wrote:
> For some use cases I am sure this kin
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
go-plugin wouldn't work?
github.com/hashicorp/go-plugin
--
-- Aldrin Leal, / http://about.me/aldrinleal
On Wed, May 17, 2017 at 7:05 PM, voidlogic wrote:
> Hey Everyone,
>
> I'm working on a project to allow other teams within my company to submit
> plugins that are executing as optional eve
