river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <michal.klec...@xpro.biz>
Subject Re: Towards Internet Jini Services (trust)
Date Tue, 12 Oct 2010 11:41:54 GMT
On Tuesday 12 of October 2010 13:33:09 Sim IJskes - QCG wrote:
> On 10/12/2010 01:11 PM, Michal Kleczek wrote:
> > On Tuesday 12 of October 2010 13:08:19 Sim IJskes - QCG wrote:
> >> On 10/12/2010 12:33 PM, Michal Kleczek wrote:
> >>> Hmm... I think I would argue that annotation should have the codebase
> >>> embedded and only issue a remote call to verify this codebase - not to
> >>> retrieve it.
> >>> 
> >>> How about we get rid of Module interface and require annotation to be
> >>> RmiModule (which is final)?
> >> 
> >> By re/encoding it as a String. So we can harden the MarshallInputStream
> >> to only accept UTF-8 String with limited length.
> > 
> > Would that be enough just not to allow recursive readAnnotation() ?
> > That way our stream would be more compact...
> It is my perception that you can feed the deserializer anything you
> want, recursive or not, as long as you limit yourself to the jre
> classes. The 'check' (at this moment) happens at the cast to String.
> And by building a babushka in the stream, cause a stackoverflow or
> heapoverflow (dependend on the implementation) in this way.

But isn't it something that always can happen if the code of objects you 
deserialize has bugs?
It does not matter if you read an annotation of "ordinary" object.

So limiting ourselves to:
1. RmiModule as annotation
2. Suppressing recursive annotation read
3. Implementing RmiModule readObject so that it only allows limited length 
string as annotation.
4. I guess you have to also do the same in Endpoint implementations (so that 
we limit hostname length)

would do the trick...
Wouldn't it?


View raw message