On Tue, May 20, 2008 at 10:42 PM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Tuesday 20 May 2008 15:21, Ian Clarke wrote: >> On Tue, May 20, 2008 at 8:42 AM, Matthew Toseland >> <toad at amphibian.dyndns.org> wrote: >> > Another worry with db4o: a lot of configuration needs to be done on the > Db4o >> > object, before creating the ObjectContainer. Once we have "untrusted >> > plugins", we will need to provide an indirection layer for plugins to call >> > the config settings they need, e.g. creating indexes, while not breaking > the >> > node (so we will need to limit what classes etc they can access), before >> > creating an ObjectContainer. We will also have to prevent untrusted > plugins >> > from accessing the static methods on Db4o. This is however a common > problem >> > for untrusted plugins: We don't have much in the way of static methods in > our >> > code, but e.g. the java service wrapper has plenty. >> > >> > So it's not a showstopper, just something to be careful of. >> >> I think as time goes on, untrusted plugins are going to be a world of >> pain, not just related to db4o, but generally :-/ Sandboxing, while >> providing the functionality they will need will be non-trivial, and >> whenever we modify the architecture its going to add a whole new >> dimension of potential trouble. > > Class loaders allow us to choose which classes a sandboxed plugin has access > to. Hopefully this is enough to keep them out of the node internals. > SecurityManager will allow us to prevent them from doing I/O etc. Java is > designed for sandboxing: granted there have been many issues with it over the > years, but it should be feasible. Anyway, it's not a reason to not use db4o.
Java JSR 277, 291 and 294 are some attempt to make modular/plugin isolation in java 7 easier . (messing with ClassLoader directly is a pain in xxx). For Java 1.3 / later, OSGi do the job quite well.
