[Mulgara-dev] adding ResolverFactoryInitializer.getSessionFactory()

Alex Hall alexhall at revelytix.com
Mon May 19 22:43:19 UTC 2008


Life is hard, and then you die wrote:
> On Mon, May 19, 2008 at 05:33:23PM -0400, Alex Hall wrote:
>> Life is hard, and then you die wrote:
>>> On Mon, May 19, 2008 at 01:07:18PM +1000, Andrae Muys wrote:
>>>> On 19/05/2008, at 11:44 AM, Life is hard, and then you die wrote:
>>>>> On Mon, May 19, 2008 at 11:36:40AM +1000, Andrae Muys wrote:
>>>>> [snip - I'll answer the rest later]
>>>>>>>> On 18/05/2008, at 3:26 PM, Life is hard, and then you die wrote:
>>>>> [snip]
>>>>>>>>> There's currently no way (that I can see) for a resolver to get a
>>>>>>>>> handle on the "current" SessionFactory (the one it belongs to);
>>>>>>>>> so I'm
>>>>>>>>> thinking of adding a getSessionFactory() to the
>>>>>>>>> ResolverFactoryInitializer to get that functionality - does  
>>>>>>>>> anybody
>>>>>>>>> have any reservations or reasons not to do this? Or any better
>>>>>>>>> suggestions?
>> I'm pretty sure that the SessionFactory that you want access to is the 
>> actual Database instance.
> 
> Actually, it doesn't matter if it's one of the wrappers
> (RmiSessionFactory, etc), but it would be better (i.e. more efficient)
> if we got the actual Database instance.

Just thought of something else... you could use the static 
ServerInfo.getServerURI() method to obtain the server URI (this field is 
set when the RmiServer starts) and send it to 
SessionFactoryFinder.newSession().  This ought to get you an 
RmiSessionFactory and shouldn't require any changes to Mulgara. 
Hopefully Java is smart enough to optimize out the RMI calls within the 
same JVM, but I'm not sure about that.

>> If this is indeed the case, I would have 
>> serious reservations about handing it out to resolvers because of the 
>> security implications.  All it would take is a cast to Database and they 
>> could wreak all sorts of havoc.  At the very least, you would need to 
>> put a wrapper around the Database to only allow Session creation.
> 
> Well, if you write a resolver you should know what you're doing. I.e.
> I consider resolvers very much "trusted" code. Sure you can wreak
> havoc, but you can do that anyway (e.g. any resolver can get the
> system-resolver and insert/delete whatever it wants to, so you really
> have to trust the resolvers you configure in).

Yes, this issue has come up before with respect to resolvers (most 
recently when Paul added default graph names).  My feeling on the matter 
is, yes resolvers are trusted to some degree; however, we should try and 
keep the ResolverFactory from doing anything that is inherently and 
obviously unsafe even if we can't (or don't want to) stop a malicious 
ResolverFactory from doing something harmful if it really wants to.  I'm 
just not sure which of those categories this particular issue falls into.

Regards,
Alex



More information about the Mulgara-dev mailing list