Is this stuff remotely relevant to the question of how to manage
iterator code in a safe and organized way?

I don't think so. I think the relationship is that we both share the
problem of how can you run dynamic code in a safe way. But after a cursory
glance, I don't see them providing any sort of infrastructure to keep
things secure.

John

On Wed, Aug 8, 2012 at 2:57 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:

> Is this stuff remotely relevant to the question of how to manage
> iterator code in a safe and organized way?
>

I haven't been closely following the River project in a while, but I actually had the same thought as Benson.  I'm no security expert so I can't give a good assessment, but I think the River folks *believe* they have an infrastructure for keeping things secure (or at least not executing code that you don't trust).  You might want to look at the net.jini.security package and sub-packages:

http://river.apache.org/doc/specs/api/net/jini/security/package-summary.html
http://river.apache.org/doc/specs/api/net/jini/security/proxytrust/package-summary.html

I'm not sure how separate the trust-related infrastructure is from the rest of River, but it might provide a useful model and starting point at least...

Thanks,
Dennis
-----Original Message-----
From: John Vines [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 09, 2012 9:50 AM
To: [EMAIL PROTECTED]
Subject: Re: River.apache.org

I don't think so. I think the relationship is that we both share the problem of how can you run dynamic code in a safe way. But after a cursory glance, I don't see them providing any sort of infrastructure to keep things secure.

John

On Wed, Aug 8, 2012 at 2:57 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:

> Is this stuff remotely relevant to the question of how to manage
> iterator code in a safe and organized way?
>

It is an interesting thought to provide an service in which authorized
users can provide jar(s) containing Accumulo iterators to be dynamically
loaded and available on request. Could have a lot of merit coupled
ACCUMULO-708.

Regardless, I like the general idea of a classloader outside of the
cluster's local filesystem. That does open the door to a lot more
difficult problems as John alluded.

I do believe it's worth noting that security is only one application of
cell-level visibility. Using visibilities/authorizations as a filtering
mechanism for application logic is an intriguing subject.

On 8/8/2012 2:57 PM, Benson Margulies wrote:
> Is this stuff remotely relevant to the question of how to manage
> iterator code in a safe and organized way?
>