Extending semantics for DynamicPolicy

[Mark Brouwer <ma...@cheiron.org>]

I'm working on something I came across at regular intervals the last few
years for some of the services I've created and that is the ability to
create class loaders from within a service that play nice in the Jini
environment, i.e. which have the right delegation model (the service as
parent), allow for proper codebase annotations and have the correct set
of permissions 'assigned' and take care of some of the 'versioning'
hassle with long running services that must be able to adopt to a
changing environment.

Due to my work for developing an improved web application server based
on Jetty that runs as a JSC Service in Seven and that can deploy and
reload plain WAR files and provides a seamless integration in a Jini
environment I came to the point I'm trying to experiment with a class
loader factory as part of Seven, as Seven provides all the class loader
tricks listed above that I need.

However there is one hurdle I can't seem to take [1] and that is
dynamically assigning permissions the the protection domains associated
with the class loaders due to the fact that Dynamicpolicy doesn't
provide a method in which you could pass in a class loader, all methods
take a class as argument. The funny thing is though that the semantics
for this methods make it clear the permissions are really assigned to
the protection domains associated with the class loader [2] for the
class passed in. The actual DynamicPolicy provider implementation also
indicates that there seems to be no reason why the DynamicPolicy
interface can't support passing in a class loader.

Any thought on this matter and if this is considered a "good thing" to
have this functionality how to approach this.

[1] I could play tricks to scan the class path of the newly created
class loader and try to get a class definition (without initializing the
class itself) and use that one to call into DynamicPolicy but this is
something I really would like to prevent.

[2] to be more correct this is "protection domains (including ones
not yet created) that are associated with the class loader of the given
class and possess at least the given set of principals"
-- 
Mark

Re: Extending semantics for DynamicPolicy

[Mark Brouwer <ma...@cheiron.org>]

Vinod Johnson - Sun Microsystems wrote:

> Would generating a dynamic Proxy class within that class loader 
> implementing no interfaces and doing a grant on that class also work? 
> (at the cost of generating a needless class)

Nifty Vinod thanks. I see no reason why it shouldn't work. The class
loader factory will hide the trick anyway and this saves me a lot of
time while not feeling like a complete hack.
-- 
Mark

Re: Extending semantics for DynamicPolicy

[Vinod Johnson - Sun Microsystems <Th...@Sun.COM>]

>
> However there is one hurdle I can't seem to take [1] and that is
> dynamically assigning permissions the the protection domains associated
> with the class loaders due to the fact that Dynamicpolicy doesn't
> provide a method in which you could pass in a class loader, all methods
> take a class as argument. The funny thing is though that the semantics
> for this methods make it clear the permissions are really assigned to
> the protection domains associated with the class loader [2] for the
> class passed in. The actual DynamicPolicy provider implementation also
> indicates that there seems to be no reason why the DynamicPolicy
> interface can't support passing in a class loader.
>
Within the context of proxy preparation it makes sense to define the 
interface this way by not requiring the caller to have (in some cases) 
RuntimePermission("getClassLoader") permission. Perhaps there were other 
reasons too.
> Any thought on this matter and if this is considered a "good thing" to
> have this functionality how to approach this.
If the feature is generally useful (and does not have any other security 
implications - nothing springs out at the moment) a corresponding method 
also probably belongs in net.jini.security.Security.
>
> [1] I could play tricks to scan the class path of the newly created
> class loader and try to get a class definition (without initializing the
> class itself) and use that one to call into DynamicPolicy but this is
> something I really would like to prevent.
Would generating a dynamic Proxy class within that class loader 
implementing no interfaces and doing a grant on that class also work? 
(at the cost of generating a needless class)

-- 
- vinod

Re: Extending semantics for DynamicPolicy

[Mark Brouwer <ma...@cheiron.org>]

Michael Warres wrote:
> Quoting Mark Brouwer <ma...@cheiron.org>:
>> However there is one hurdle I can't seem to take [1] and that is
>> dynamically assigning permissions the the protection domains associated
>> with the class loaders due to the fact that Dynamicpolicy doesn't
>> provide a method in which you could pass in a class loader, all methods
>> take a class as argument. The funny thing is though that the semantics
>> for this methods make it clear the permissions are really assigned to
>> the protection domains associated with the class loader [2] for the
>> class passed in. The actual DynamicPolicy provider implementation also
>> indicates that there seems to be no reason why the DynamicPolicy
>> interface can't support passing in a class loader.
> 
> FWIW, the API was fashioned this way since a caller might not have permission
> to obtain the class loader of the class to which it wished to grant
> permissions.  IIRC, I don't think there was anything intrinsically wrong with
> passing in a class loader directly--there simply wasn't any use case at the
> time to justify an additional method.

Hi Michael,

Forgot to respond on Vinod's posting mentioning that I'm aware why the
API is as it is, logical given its purpose of proxy preparation. I don't
know whether we should pursue the enhancements I first mentioned as
Vinod's 'trick' makes it possible to get what you want and probably it
will stay a rare use case, but if other feel different about this I have
no problem in creating an issue for it.
-- 
Mark

Re: Extending semantics for DynamicPolicy

[Michael Warres <mp...@acinion.com>]

Quoting Mark Brouwer <ma...@cheiron.org>:
> 
> However there is one hurdle I can't seem to take [1] and that is
> dynamically assigning permissions the the protection domains associated
> with the class loaders due to the fact that Dynamicpolicy doesn't
> provide a method in which you could pass in a class loader, all methods
> take a class as argument. The funny thing is though that the semantics
> for this methods make it clear the permissions are really assigned to
> the protection domains associated with the class loader [2] for the
> class passed in. The actual DynamicPolicy provider implementation also
> indicates that there seems to be no reason why the DynamicPolicy
> interface can't support passing in a class loader.

FWIW, the API was fashioned this way since a caller might not have permission
to obtain the class loader of the class to which it wished to grant
permissions.  IIRC, I don't think there was anything intrinsically wrong with
passing in a class loader directly--there simply wasn't any use case at the
time to justify an additional method.

-Mike