Exported resources

[Bryan Atsatt]

1. Definitely agree that resource search order should be identical to
class search order.

2. Using permissions to limit access to private resources seems like
overkill to me. The prototype implemented this in a very simple fashion:

a. If resource is exported, return it, else
a. Get the caller's Module (get class from stack, get module from it)
b. If callerModule == this, return resource, else return null.

// Bryan

Stanley M. Ho wrote:
> 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
>