----- 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 <ge...@cox.net> wrote:
> > > > > > > On Mar 4, 2014, at 12:02 AM, Michał Kłeczek
> > > > > > > <michal.klec...@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.klec...@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" <j...@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
