There is a huge misunderstanding here.
I am pretty confident I understand and know how River works (at least up
to version 3.0 exclusive)
And my questions are not about how things are implemented but what
changes Peter is proposing.
Especially in the context of all the discussions that are held here
around security, OSGI, serialization etc.
The questions are very detailed and technical - because there is a lot
of things that are not clear
in the proposed designs.
For example - saying that "deserializing an object is secure because
it is a dynamic proxy" is simply misleading. That is why I ask more
questions.
You might call it "demanding your time" but it shouldn't stop anyone
from asking questions.
Cheers,
Michal
Gregg Wonderly wrote:
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<mic...@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<j...@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<mic...@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
