river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River-436 - need some explanation of preferred class provider
Date Fri, 07 Mar 2014 09:52:04 GMT
Actually, Distributed could dovetail nicely with a modular service provider, by decoupling
implementation from state, object state can be migrated to alternate implementations, remotely,
or even locally within the same jvm.

Cheers,

Peter.

----- Original message -----
> ----- Original message -----
> > Peter,
> > 
> > I must say that Distributable looks really cool - simple and elegant.
> 
> It'd be nice to see it catch on!
> 
> > 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 :)
> 
> I wanted to prevent constructors being used on ClassLoader, Sockets and
> also prevent using private or package private constructors or basically
> creating objects that shouldn't be serialised.   The reason is, the
> object that's about to be created has no ProtectionDomian yet on the
> stack.   An object can of course perform a PrivilegedAction from within
> its constructor, so this seemed like a reasonable compromise.
> 
> 
> Cheers,
> 
> Peter.
> 
> > 
> > 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
> 
> <Attachment>    Michał Kłeczek (XPro).vcf
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message