Exported resources

[Stanley M. Ho]

Hi JSR 277 experts,

This is regarding the semantic of exported resources in a module, and it
is one of the outstanding issues in the updated specification (Section
7.3.2.2) that I would like to get your inputs. There are two aspects of
the issue:

1. Search order for resources in module classloader

This is related to what happens when a resource is requested through the
module classloader:

        module.getClassLoader().getResource(String)
        module.getClassLoader().getResourceAsStream(String)
        module.getClassLoader().getResources(String)

The updated specification already defines the search order for classes
in the module classloader based on the declared import order and
re-export (see Section 7.3.1), and classloading is delegated based on
the exported classes from the imported modules.

In our earlier discussion, I think many EG members expected that the
search order for resources would be similar to that for classes.
Therefore, I propose that the search order for resources in the module
classloader would also be based on the declared import order and
re-export similar to the algorithm described in Section 7.3.1, and
resource loading would be delegated based on isResourceExported() from
the imported modules accordingly.


2. Enforcement of access control

There are two notions of resources: exported and private. Ideally, if a
resource is exported, it would be visible and accessible through the
module classloader regardless the caller; on the other hand, if a
resource is private, it would be visible and accessible through the
module classloader only if the caller is the module containing the resource.

Unlike Java classes, there is no access control supported for resources
in the JVM, so we will need to come up a scheme to support the semantic
we want. Supporting exported resources should be straightforward - the
module classloader can simply return the exported resources whenever
they are requested; supporting private resources is a bit complicated,
and this is what I want to go into more details.

To enforce the access of private resources, one reasonable approach is
based on security permission. Each module would be assigned with certain
permission to access its own resources. When a private resource is
requested though the getResource()/getResourceAsStream()/getResources()
method of the module classloader, the module classloader would perform
security check to determine if the caller has the appropriate permission
  before the private resource is returned; otherwise, the module
classloader would pretend the requested resource does not exist.
Apparently, the .NET Framework uses a similar approach to enforce access
to resources embedded/linked in the Assembly:

http://msdn2.microsoft.com/en-us/library/xc4235zt.aspx
http://msdn2.microsoft.com/en-us/library/5kx66y1a.aspx

This security permission approach should be sufficient to prevent
untrusted code (e.g. applets, JNLP applications, etc.) to access private
resources in other modules to exploit potential vulnerability. On the
other hand, if the caller has all permissions, it can freely access the
private resources in other modules, and this security permission
approach would break down. That said, if the caller has all permissions,
it can pretty much do whatever it wants anyway, and this is consistent
with the existing behavior. Note that if a module has an exported class
and one of its public method loads private resources internally, the
developers might be required to put a doPrivileged() block around the
resource loading code in this method for the private resources to be
loaded successfully. Another implication is that the performance of
accessing private resources would be slower compared to exported
resources, because of the overhead of the permission check; this
performance characteristic may not be what developers would expect.

That's it. Let me know your inputs. If you have better suggestions to
deal with this issue, I would definitely like to hear them.

- Stanley