Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins and Sandboxing #9

Open
mkotb opened this issue Jun 29, 2018 · 0 comments
Open

Plugins and Sandboxing #9

mkotb opened this issue Jun 29, 2018 · 0 comments

Comments

@mkotb
Copy link
Member

mkotb commented Jun 29, 2018

So part of this includes writing a small Plugin API portion of Remonic to allow developers to (mostly) add different integrations into the server. Elements to consider:

  • Do we want/need to use a prebuilt framework for this? (See: https://github.com/pf4j/pf4j) For the record, it also supports Kotlin. How much work does PF4J do for us, and is it worth relying on other software to do it?
  • How do we want libraries and dependencies to work? (i.e: Should they be defined and the dependencies are loaded separately?) Issues can arise when two plugins depend on X and package them in their jar, and now there are two versions of dependency X in the ClassLoader.
  • How should the server itself pull or get the data it needs from the plugins? Possible ideas: Event system, interfaces which are extended (PF4J is built upon this with extension points)

Second extremely important point: Sandboxing

We would need an effective, configurable SecurityManager. It may be a good idea to whitelist actions instead of blacklisting them, just for the sake of completeness. Plugins need to be able to:

  • Make network connections
  • Host a ServerSocket if need be
  • Pull information from the database (i.e interact with Exposed)
  • Create, read, and write to files (This would be discouraged but for edge cases, they should have the ability to)

They should not be able to:

  • Access database connection info and configs
  • Override HTTP Endpoints for the API
  • Access user password data (This would be a challenge as they still need to be able to access other information from the database. Maybe disallow access of User data at all?)

At the end of the day, though, these options should be configurable and specific plugins should be able to be granted exceptions to these rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant