Some more thoughts.
There is one scenario that is not covered here:
I get an service, verify the module that loads its class using a
ModuleAuthority that I trust. This service in turn downloads some other
objects that it verified. There is no way I can delegate trust verification to
the service - I must trust Modules (actually ModuleAuthorities) of those
subsequent objects.
1. I have to have a way to allow or disallow module trust delegation (looks
like a case for dynamic permission grants)
2. This delegation has to be automatic (IOW the service does not have to do
anything - it is solely my decision to delegate)
Any ideas?
Michal
On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
> So...
> I've spent a day on some thinking and prototyping and hopefully I got an
> idea. Here is an outline:
>
> 1. We annotate classes with an object implementing Module interface:
> interface Module {
> //methods copied from ClassLoading but there is no annotation argument
> Class loadClass(...);
> Class loadProxyClass();
> }
> This makes class loading pluggable - a service can designate it's own class
> loading mechanism.
> Note that the methods take boolean verifyCodebaseIntegrity argument. I
> think it could be replaced by placing constraints on a Module.
>
> 2. Before using a Module we prepare it using a ProxyPreparer - that way we
> make sure we trust the Module before letting it load classes
>
> 3. We have a default implementation of Module that delegates class loading
> to ClassLoading:
> RmiModule implements Module {
> private String annotation;
> }
>
> 4. There is a single instance of RmiModule called BOOTSTRAP that we use to
> load RmiModule class. This is implemented in:
> RmiModule {
> ...
> static Module getModuleOf(final Class cl) {
> /*
> * RmiModule is equivalent of String annotation
> * so it should be available locally
> */
> if (cl == RmiModule.class) {
> return getBootstrap();
> }
>
> final ClassLoader loader = getClassLoader(cl);
> if (loader instanceof ModuleClassLoader) {
> return ((ModuleClassLoader) loader).getModule();
>
> }
>
> final String annotation = RMIClassLoader.getClassAnnotation(cl);
> return annotation != null ? RmiModule.getInstance(
> annotation,getModuleTrust(loader)) : getBootstrap();
> }
> ...
> }
>
> 5. We use the above method in annotateClass and annotateProxyClass of our
> MarshalOutputStream
>
> 6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
> implementation delegates TrustVerifier retrieval to:
> public interface ModuleAuthority extends Remote {
> TrustVerifier getModuleVerifier() throws RemoteException;
> }
>
> 7. We implement some helper functions that make it simpler to export a
> service and provide its clients with either third party ModuleAuthority or
> designate itself as a ModuleAuthority.
>
> 8. Before all this is implemented in PreferredClassProvider we have to
> cache association between a ClassLoader and a Module. It's implemented in
> RmiModule.
>
> 9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
> reference to associated Module
>
> 10. If we implement it in PreferredClassProvider we can have different
> ClassLoaders for the same annotation but different ModuleAuthority - that
> would actually allow us to grant permissions to Modules - before that two
> different Modules with the same annotation are going to share permissions.
>
> I've attached a prototype implementation (note - it is a proto-proto-
> prototype) so that you guys can verify if you have some spare time.
> Don't know if mailing list server allows attachments.
>
> Michal
>
> On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
> > On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> > > On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > > > When I think about it some more - the below idea is not enough and we
> > > > need a more general solution.
> > > > How about class annotation not being a String but rather an object...
> > > > I have to give it some more thought.
> > >
> > > There are been some thought and discussion about doing this. It is
> > > possible, but the problem becomes that if you send an object with the
> > > annotation, then how does the receiver unmarshall that object? Is that
> > > object something that everyone knows about ahead of time?
> >
> > My line of thought was - yes. It would have to be something similar to
> > ProxyTrust - a factory to receive an Unmarshaller.
> > I haven't really given it enough thought.
> >
> > But I am more and more convinced that doing that at the higher (proxy
> > preparation) level - as I described it earlier - could actually be
> > enough.
> >
> > Michal
