On Tuesday 20 May 2008 15:21, Ian Clarke wrote: > On Tue, May 20, 2008 at 8:42 AM, Matthew Toseland > <[EMAIL PROTECTED]> 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. > > Ian.
pgp76RLgWYgaw.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
