Exported resources

[Stanley M. Ho]

Hi Bryan,

Bryan Atsatt wrote:
> ...
> No, I don't agree. That's what I said before :^). I *really* don't like
> the idea that I'm going to have to explicitly grant permission to some
> module to access my resource. This *significantly* complicates

No, this was not what I suggested. If some other modules want to access
your resource, your resources need to be exported. However, if you want
to access your own private resource in your module (call
ClassLoader.getResource*() directly or call ResourceBundle.getBundle(),
etc.), then your code would require additional permissions.

> deployment. How will the grant occur, especially given that each
> environment can use an entirely different permission storage mechanism?
>
> Or are you thinking that the loaders in the module system will construct
> ProtectionDomains pre-wired with permissions? If so, exactly which
> entities will be blessed? Just the JRE code? What about all the existing
> non-JRE frameworks in use?

When your module instance is initialized, the module system can
construct the ProtectionDomain with the appropriate permissions and
associate that with the classes in your module, so your classes in your
module will always have the necessary permissions to access your own
resources.

> Sure, resources have never had JVM access control applied to them. But I
> don't think we should go to the other extreme (permissions) just so that
> I can give "friend" access to private resources. I'd much prefer that
> such resources simply be exported.
>
> And I don't see this as a particular problem, either. We've gotten along
> just fine without private resources so far (or maybe there is some big
> demand for this that I'm missing?).
>
> And what about the mismatch issue I brought up? Lots of existing
> frameworks use the "services" pattern, in which:
>
> 1. A well known resource name is used in a getResource() call.
> 2. The resource contains a string naming a provider class.
> 3. The provider class is loaded using Class.forName().
>
> This is a simple but very powerful pattern, but it requires that *both*
> the resource and the named class be accessible to the framework. If we
> require a permission grant for the resource, but not for the class, it
> will be very easy to get access to one and not the other. Is it really
> worth opening up this potential headache to enable a friend model for
> resources?
>
> // Bryan

Note that the security permission approach can be abused if a module has
all permissions, it can access even the private resources in other
modules. This is the friend access as you mentioned, but this is not my
intention of using the security permission approach.

Sorry, I have to go and I can't response in details here. Are you saying
that we should probably give up the idea of exported/private resources
and make all resources in a module to be always public and accessible?
Or are you saying that you still like the idea of exported/private
resources but you don't like to address it using the security permission
approach?

- Stanley