river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Thu, 16 Feb 2017 21:15:54 GMT
The important detail is to understand that there is nearly a decade of development and design
with experiences driving most of that around what exists today.  Peter, nor really anyone
any longer, can not “answer” all the questions you might have in a short amount of time.
 I sense that you have a view of how things should work, and believe that because that is
not the case, that we need to “fix it.”   I am not suggesting, nor do I sense Peter is,
that there is nothing to fix or improve with River.  However, it’s important to understand
how River was designed to work, and that will require you to study, from several angles, the
details.  Yes, the code is hard to read.  It doesn’t just calculate numbers, or arrange
data in collections.  Instead, it is interacting with the various details of security, class
loading and JVM reflection to provide a flexible mechanism for RPC.  I know, that you know,
that there are a lot of technologies that exist today, which did not exist at the time that
River was created as Jini.  Instead, people without knowledge of many things that already
existed to solve their problems went off to make software that works and looks the way that
they thought it should for RPC or messaging at some RPC like level, and now we have a diverse
set of technologies which all, in the end, allow network based communications to happen.

River’s way of doing it, is but one.  It’s not perfect and it needs work.  Please understand
that Peter and others have ideas for things/changes which will improve the user experience
of River.  What we are trying to do, is to understand your perspective better.  The questions
and comments/answers here are not going to be very good if you are just demanding our time,
and not spending your time to learn the details what Peter is pointing out about how River
works.

Gregg


> On Feb 15, 2017, at 1:00 AM, Michał Kłeczek <michal@kleczek.org> wrote:
> 
> They are valid questions and you haven't answered any of them.
> I've described _your_ way of thinking (which I do not agree with).
> 
> Apache River has many problems both technical and organizational.
> But I find the idea interesting and was expecting openness
> for contributions and open discussion.
> 
> This is an open source project and there are no obligations to take part in the discussion
nor answer any questions.
> But I find your patronizing statement disincentive to contribute to this project - especially
that you are one of its main contributors.
> 
> Regards,
> Michal
> 
> Peter wrote:
>> Finding the answer to this question should assist you to discover answers to many
of the other questions you've had.
>> 
>> While I've done my best to answer as many of your questions as I can, time is limited
and I haven't had time to answer all of them or rebutt or confirm all arguments /  assumptions.
 Sometimes the right questions are more important than answers.
>> 
>> Regards,
>> 
>> Peter.
>> 
>> Sent from my Samsung device.
>>     Include original message
>> ---- Original message ----
>> From: Peter<jini@zeus.net.au>
>> Sent: 15/02/2017 12:58:55 pm
>> To: dev@river.apache.org<dev@river.apache.org>
>> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
>> 
>> The PreferredClassLoader will attempt to download the jar file in order to get the
preferred list.
>> 
>> DownloadPermission should be called DefineClassPermission, I don't think it will
prevent download of the jar per say.
>> 
>> Why must the bootstrap proxy be loaded by the codebase ClassLoader?
>> 
>> Regards,
>> 
>> Peter.
>> 
>> Sent from my Samsung device.
>>     Include original message
>> ---- Original message ----
>> From: Michał Kłeczek<michal@kleczek.org>
>> Sent: 15/02/2017 06:20:37 am
>> To: dev@river.apache.org
>> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
>> 
>> So I've given it some thought and the only explanation I can come up  with is: 
>> 1. To create an instance of the bootstrap proxy you need the codebase  annotation.
2. Codebase annotation is needed because you want the bootstrap proxy's  class to be defined
in the proper codebase ClassLoader 3. Since you do not want to allow any code downloads before
placing  constraints on the bootstrap proxy - it has to be a dynamic proxy. That way its class
can  be defined by the codebase loader and yet no code is downloaded 
>> So the overall sequence is as follows: 1. Get the codebase annotation and create
the codebase loader 2. Create an instance of a dynamic proxy of a class defined by the  codebase
loader 3. IMPORTANT - before creating the proxy instance DO NOT grant any  download permissions
- that way we are sure the proxy does not triggers any code download and  execution due to
it implementing some foreign interfaces 4. Once the proxy is instantiated - grant its ClassLoader
download  permissions 5. Place the constraints on the proxy 6. Invoke a remote method on the
proxy 
>> I understand the whole thing is to make sure the bootstrap proxy is defined by the
codebase ClassLoader - and the ClassLoader is needed  to be able to dynamically grant download
permissions. 
>> What I DO NOT understand is - why the download permissions are needed at  all? Since
the bootstrap proxy's code MUST be local code - why not simply  have its class defined by
the context ClassLoader? Since downloading code is done only after authentication anyway -
I  don't see the reason to use DownloadPermissions at all. 
>> The only thing that comes to mind is that it is to make sure the service is not able
to download code from a codebase different than its own. 
>> Which is OK but redundant. The reasoning is: Since the code of the service proxy
is already trusted (we have  established trust before downloading it) - we can simply place
the constraints on the service proxy that instructs  it to only download code meeting certain
criteria. 
>> Am I correct in my thinking? 
>> Thanks, Michal 
>> Michał Kłeczek wrote:
>>>  Let me dig some deeper. Comments inline.     Peter wrote:
>>>>  Yes the dynamic proxy's are 100% local code.  Remember dynamic    proxy's
don't have codebase s. :)
>>>  Of course they do - look at PreferredClassProvider - the dynamic proxy    class
is defined by the codebase loader!     Being a dynamic proxy does not mean there is no codebase.
>>>>    AtomicMarshalInputStream performs a special input validation on    java.lang.reflect.Proxy
thus ensuring the InvocationHandler is also    trusted.  If the InvocationHandler doesn't
pass the test the proxy's    never created.
>>>  Why does it only verify dynamic proxies? Doesn't it verify normal    objects?
>>>>    The dynamic proxy's put you in direct contact with the service    provider
using only local code with input validation constrained over    secure connections (as configured
with constraints in force).     I think I've given you enough info now to investigate further.
>>>  Ok - so your "token" is the same thing as my SmartProxyWrapper. Let's    call
it a "bootstrap proxy", ok?     1. What interface this bootstrap proxy implements?   2. Why
do you think it has to be a dynamic proxy (ie. an instance of a    subclass of java.lang.Proxy)?
  3. What and when are DownloadPermissions required? How do they add to    the overall security?
  I understand the security of service proxies is enforced by the    constraints placed on
the bootstrap proxy.   So where is the place for DownloadPermissions?     4. Finally - how
is the lookup service proxy verified? Does it also    provide the bootstrap proxy?   If so
- what special role does it play in the architecture?   The bootstrap proxy does not have
to be provided by the lookup    service, does it?     If it is verified differently - why
and how?     Thanks,   Michal
>> 
>> 
>> 
>> 
>> 
>> 
> 


Mime
View raw message