river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: River-436 - need some explanation of preferred class provider
Date Thu, 06 Mar 2014 16:23:56 GMT
Peter,

I must say that Distributable looks really cool - simple and elegant. The only 
thing that I would actually remove is setting up an untrusted object security 
context in SerialReflectionFactory.create(). It is not really needed _iff_ the 
code you are executing is already trusted :)

Regards,

On Thursday, March 06, 2014 09:42:50 PM Peter wrote:
> Also worth noting is an interface called Distributed, this is an alternative
> to Serializable.  Underneath the covers it uses Externalizable, so it's
> fast, it also uses constructors, so objects can use final fields and
> preserve invarients and subclass non serializable objects without no arg
> constructors.  Internal state of Distributed objects are not published and
> objects can evolve freely, provided they maintain constructor method
> signatures.  In fact, you can use interfaces, static factory methods and
> builder objects, so your Distributed implementation can be package private
> and be completely replaced with another implementation even with a totally
> different class name, think providers
> 
> Total and complete freedom from Serializable warts, but completely
> compatible, leveraging Object Input and Output streams and the entire
> existing Serializable infrastructure.
> 
> Combined with remote reflection proxies and lambda based services with
> dynamic remote code generation, we'll be on the doorstep of distributed
> compute nirvana.
> 
> Downloaded code may soon be irrelevant to distributed computing and with it
> versioning and ClassLoader issues.
> 
> Takes a little time to sink in though.
> 
> The next question for those daring enough to ask "Where will the future take
> us?"
> 
> Cheers,
> 
> Peter.
> 
> ----- Original message -----
> 
> > River doesn't prevent using OSGi, in fact, we are making changes to
> > enable it, we also want to support Maven, but we don't currently mandate
> > using either.
> > 
> > I'd reccomment keeping services simple and ensure you only share common
> > public interfaces and classes (service api) and ensure these shared
> > classes are installed locally on your clients.
> > 
> > As for security that will be fixed in a following release and we are
> > making steps towards that.
> > 
> > Even for OSGi, without River, deserialisation is complex beast.
> > 
> > With Java 8, we'll be looking at lambda based services where code is
> > dynamically generated at the server, it's an inversion of control that
> > will allow much more flexibility.   In fact I'd reccommend avoiding
> > downloaded code, if it can be avoided, or at least keep it simple and
> > ensure all shared classes are installed locally.
> > 
> > If you have a solution to ClassLoader issues, I'm all ears, honestly
> > though, ClassLoaders are a Java issue, we do our best to work around
> > them, I'm not aware of a silver bullet.   Beware of complex ClassLoader
> > relationships, as these can lead to deadlock.
> > 
> > Cheers,
> > 
> > Peter.
> > 
> > ----- Original message -----
> > 
> > > Greg,
> > > 
> > > I cannot agree more with the statement that mobile code is the
> > > cornerstone of    River. I do not want to send just "data"
> > > (XML/JSON/whatever). I want to    exchange _objects_ (data + code -
> > > well... in the end it is all data :-) ). And    I want it to be _secure_
> > > and ubiquitous. IMHO we should just make it work - because it simply
> > > does not work at this    moment - as shown in my example.
> > > 
> > > What I'm arguing is that it is not fixable with hierarchical class
> > > loading. The    problem is that the client simply does not know what
> > > should be the "parent"    when deserializing objects. Your River-336
> > > patch is not going to change it    (while still important since
> > > RMIClassLoader dependency is really a PITA).
> > > 
> > > I am not proposing any particular solution at this moment - BUT I would
> > > really    like the community to have a second look at existing solutions
> > > before coming    up with yet another one.
> > > 
> > > The requirements - as I see them right now would be:
> > > 
> > > 1. Make it possible to exchange arbitrary object graphs composed of
> > > objects    which classes are from _different_ codebases.
> > > That would make it possible to create smart proxies wrapping other
> > > services'    smart proxies (which in theory is possible today... but in
> > > practice is not)
> > > 
> > > 2. Do not allow yet untrusted code to execute. Ever.
> > > It basically means that from security perspective current algorithm:
> > > - deserialize an object
> > > - ask it for secure proxy
> > > - ask the secure proxy for a verifier
> > > - verify the original object
> > > is just simply wrong :)
> > > What's more - if we only allow trusted code to execute then the whole
> > > proxy    verification problem becomes much simpler - all those
> > > complicated   UntrustedObjectSecurityContext tricks are no longer
> > > necessary - it is enough    to just ask an object to verify itself
> > > (placing apropriate invocation    constraints on it first).
> > > 
> > > The River-436 patch is going to (mostly) solve 2. The only potential
> > > holes    left are in unicast response parsing where ObjectInputStream is
> > > created to    read MarshalledInstance from the network - opening
> > > possibility of DOS or other    attacks exploiting local code
> > > vulnerabilities. It is also going to open a possibility to solve 1
> > > because it is going to make    class loading algorithms
> > > extensible/dynamic.
> > > 
> > > The big question is whether it is possible to fix 1 without imposing
> > > any   "container" or "class loading scheme" on the client/service
> > > implementor.
> > > 
> > > OTOH - while we do not provide any "container" today - we do provide a
> > > "platform". There is no way any client can work without having jsk-
> > > platform.jar in its classpath and without specifying
> > > PreferredClassProvider as    RMIClassProvider and configuring httpmd url
> > > handler.
> > > 
> > > Regards,
> > > 
> > > On Tuesday, March 04, 2014 08:03:13 PM Gregg Wonderly wrote:
> > > > One of the greatest things about Java is serialization and mobile
> > > > code!    One of the most limiting aspects of any language is
> > > > Serialization!
> > > > 
> > > > If you have an interface or data class that two classes need to
> > > > access, there is no choice but to have a common parent class loader.
> > > >     Your client can institute such as class loading scheme completely
> > > > independently of Jini’s use of some other class loading scheme,
> > > > provided that you at least allow the “parent load this please”
> > > > mechanism of hierarchical class loading to occur.
> > > > 
> > > > My changes to remove the explicit reliance/dependence on
> > > > RMIClassLoader in River-336, and instead allow you to plug in how the
> > > > “parent load this please” call out to work, is how you can solve this
> > > > so that it actually works for your clients special needs.    The best
> > > > thing is that this mechanism can be plugged into, at runtime, whereas
> > > > RMIClassLoaderSPI is a onetime thing that requires access to the app
> > > > class loader, which might not be possible in some clients.    All that
> > > > is required is a security grant that allows a particular codebase to
> > > > plugin a specific class name.
> > > > 
> > > > Gregg Wonderly
> > > > 
> > > > On Mar 4, 2014, at 7:39 PM, Gregg Wonderly <gergg@cox.net> wrote:
> > > > > > On Mar 4, 2014, at 12:02 AM, Michał Kłeczek
> > > > > > <michal.kleczek@xpro.biz> wrote:
> > > > > > 
> > > > > > The real problem is that Util interface is in two codebases.
It
> > > > > > should be in a single codebase shared between UtilProxy and
> > > > > > WrapperProxy. But to make it possible we would need to have
peer
> > > > > > class loading like in ClassWorlds or OSGI.
> > > > > > It is not solvable in a standard hierarchical class loading
> > > > > > scheme.
> > > > > 
> > > > > This is one of the good examples of where hierarchical loading can
> > > > > present challenges.
> > > > > 
> > > > > But the question really is, can an arbitrary client really expect
> > > > > for arbitrary services to interact correctly?    If you want them
> > > > > to do this, it has been shown over and over that global types are
> > > > > the best, least troublesome choice.
> > > > > 
> > > > > If you want ubiquitous interactions why not use string based values
> > > > > such as XML or better yet, JSON?
> > > > > 
> > > > > Then code and data is immune to class loading snafus and not bound
> > > > > to a container or hosting "standard"!
> > > > > 
> > > > > Gregg
> > > > > 
> > > > > > Anyway... It is not really River-436 problem so my patch proposal
> > > > > > is going
> > > > > > to have the same issue since it is just a replacement for String
> > > > > > annotations and not change in class loading scheme.
> > > > > > 
> > > > > > Thanks,
> > > > > > Michal
> > > > > > 
> > > > > > 4 mar 2014 06:38 "Michał Kłeczek" <michal.kleczek@xpro.biz>
> > > > > > 
> > > > > > napisał(a):
> > > > > > > 1. The problem is there is no such thing as "the service
> > > > > > > interface". It is
> > > > > > > context dependent. What is "the service interface" for
service
> > > > > > > browser?
> > > > > > > 
> > > > > > > 2. In this particular case Util interface is an implementation
> > > > > > > detail of WrapperProxy. It is Wrapper interface the client
is
> > > > > > > interested in. So I would say it should be preferred in
> > > > > > > WrapperProxy codebase.
> > > > > > > 
> > > > > > > 3. Even if Util is not preferred in WrapperProxy codebase
we
> > > > > > > still have ClassCastException if the client does not have
Util
> > > > > > > in its classpath. Why
> > > > > > > should it? it is interested in Wrapper not in Util. So
either
> > > > > > > a. We always get ClassCastException if Util is preferred
in
> > > > > > > WrapperProxy codebase, or
> > > > > > > b. We get ClassCastException anyway if a client does not
have
> > > > > > > Util in its
> > > > > > > classpath.
> > > > > > > Let's say I want to register RemoteEventListener that wraps
a
> > > > > > > Javaspace proxy to write events in a space. Does that mean
the
> > > > > > > service "event source"
> > > > > > > has to be aware of Javaspace interface??? That would be
> > > > > > > absurd...
> > > > > > > 
> > > > > > > It all does not have anything to do with codebase services.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Michal
> > > > > > > 
> > > > > > > 4 mar 2014 00:09 "Peter" <jini@zeus.net.au> napisał(a):
> > > > > > > > The Util interface should not be preferred.    Implementations
> > > > > > > > of Util can
> > > > > > > > be preferred but not Util itself.
> > > > > > > > 
> > > > > > > > Services need a common api that all implementations
and
> > > > > > > > clients can use to interract, even if this is a kind
of
> > > > > > > > codebase service.
> > > > > > > > 
> > > > > > > > Modifying an interface is generally considered bad
practise
> > > > > > > > but now Java
> > > > > > > > 8 makes it possible to add default methods for added
> > > > > > > > functionality, that
> > > > > > > > line blurs somewhat.    What can you do if an earlier
> > > > > > > > interface is loaded by
> > > > > > > > a parent ClassLoader and you need a later version,
make it
> > > > > > > > preferred?
> > > > > > > > 
> > > > > > > > My thoughts are that interfaces should never be preferred
and
> > > > > > > > all classes
> > > > > > > > defined in their methods shouldn't be preferred either.
> > > > > > > > 
> > > > > > > > It would be relatively easy to write a new implementation
> > > > > > > > that ensures that interfaces are loaded into their
own
> > > > > > > > ProtectionDomain in a parent ClassLoader.    But that
would be
> > > > > > > > confusing as dynamic policy grants are made
> > > > > > > > to ClassLoader's not ProtectionDomains.
> > > > > > > > 
> > > > > > > > But using ProtectionDomains in this manner, preserves
> > > > > > > > security, ensures maximum visibility and avoids codebase
> > > > > > > > annotation loss, if we ask the ProtectionDomain for
the
> > > > > > > > annotation, instead of the ClassLoader.    But this
> > > > > > > > is not how we do things presently.
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > Peter.
> > > > > > > > 
> > > > > > > > ----- Original message -----
> > > > > > > > 
> > > > > > > > > But it will also be loaded by WrapperProxy ClassLoader,
> > > > > > > > > since it is preferred there. So it will end up
with
> > > > > > > > > ClassCastException, right?
> > > > > > > > > 
> > > > > > > > > Regards,
> > > > > > > > > Michal
> > > > > > > > > 
> > > > > > > > > If Util is installed locally, it will only be
loaded by the
> > > > > > > > > application
> > > > > > > > > ClassLoader, since it isn't preferred.
> > > > > > > > > 
> > > > > > > > > Peter.
> > > > > > > > > 
> > > > > > > > > ----- Original message -----
> > > > > > > > > 
> > > > > > > > > > Folks,
> > > > > > > > > > while woking on the River-436 patch proposal
I've came
> > > > > > > > > > across the scenario that I am not sure how
to handle:
> > > > > > > > > > 
> > > > > > > > > > Utility service:
> > > > > > > > > > //inteface is NOT preferred
> > > > > > > > > > interface Util {...}
> > > > > > > > > > //class IS preferred
> > > > > > > > > > class UtilProxy implements Util {}
> > > > > > > > > > 
> > > > > > > > > > Wrapper service:
> > > > > > > > > > //NOT preferred
> > > > > > > > > > interface Wrapper {}
> > > > > > > > > > //preferred
> > > > > > > > > > class WrapperProxy implements Serializable{
> > > > > > > > > > //initialized with Util impl from a lookup
service
> > > > > > > > > > private Util util;
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > Wrapper service codebase includes Util interface
but it
> > > > > > > > > > is
> > > > > > > > 
> > > > > > > > _preferred_.
> > > > > > > > 
> > > > > > > > > > Would deserialization of WrapperProxy end
with
> > > > > > > > > > ClassCastException? From what I understand
UtilProxy is
> > > > > > > > > > annotated with its codebase. When deserializing
UtilProxy
> > > > > > > > > > a ClassLoader is going to be created with
parent set to
> > > > > > > > > > TCCL. It means Util interface is going to
be loaded twice
> > > > > > > > > > by two ClassLoaders - one for WrapperProxy
codebase and
> > > > > > > > > > another for UtilProxy codebase.
> > > > > > > > > > 
> > > > > > > > > > Am I correct?
> > > > > > > > > > And if so: is it desired behavior?
> > > > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Michał Kłeczek
> > > > > > > > > > XPro Quality Matters
> > > > > > > > > > http://www.xpro.biz
> > 
> > <Attachment>    Michał Kłeczek (XPro).vcf

-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
Mime
View raw message