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. > > Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080520/560b17b4/attachment.pgp>
