river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Fri, 12 Dec 2008 18:14:50 GMT
----- Original Message ----

> From: Gregg Wonderly <gergg@cox.net>
> To: river-dev@incubator.apache.org
> Sent: Friday, December 12, 2008 12:46:54 PM
> Subject: Re: Split JavaSpaces and JINI
> Wade Chandler wrote:
> >>> From: Gregg Wonderly 
> >> Well one issue with netbeans is the fact that it doesn't have a real 
> SecurityManager implementation.  It's not pluggable either.  That means that if 
> I put together a Jini module for netbeans, and it has discovery and code 
> download in it, I am opening the users to viral services.  That door has to be 
> closed.  I brought it up more than a year ago.  I haven't had any chance to work 
> on this issue with the dev team, other than some discussion that melted away.
> >> 
> > 
> > Hmm. I'm missing your point here.
> If you create a Jini module that runs inside of the IDE, and that module does 
> service discovery, to allow you to select from a list of visible services, which 
> service you want to interact with, it must instantiate every service object 
> discovered (MarshalledObject.get()) before it will present any of the results of 
> the service discovery.
> If you look at the API for ServiceRegistrar.lookup() (there are two instances),  
> you can see that either you get a live Object that is the service proxy, or you 
> get a ServiceMatches with an array of ServiceItem, each of which has a 
> ".service" member with a live object.  This means that if you have no security 
> enabled, I can put a rogue lookup server on the network (where your lookup can 
> see it), and register viral services in it.  When you find one of those 
> services, and it deserializes, the readObject() or readExternal() runs, and I 
> can do whatever I want, based on the active security manager, even though you 
> might not elect to use the service and call any methods on it.

Understand. Yes, I was overlooking having to lookup them all up to display them etc versus
thinking of known services.

> The netbeans security manager does next to no file access checks because that 
> was seen as a performance problem.  But they have to have a security manager 
> active to do RMI calls, so they hacked a SecurityManager together that leaves 
> things pretty open last I looked.
> This is why we must have the ability to do lookup without unmarshalling in order 
> for users to have half a chance at safely doing anything without full JERI 
> security turned on.  It must be possible to guarantee "nothing unexpected", or 
> we'll just be the next Microsoft...

Heh heh, yes, there needs to be a way to inspect the service, some credentials, without unmarshalling.
A way to ask for all services out there, the class or interface they implement, along with
other user identification information such as a displayable name, description, version, etc
I would think. What about this list? Anyone have a link to an archive? I want to find your
other email Gregg and see what you wrote about there.



Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

View raw message