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
