Exported resources

[Bryan Atsatt]

Stanley M. Ho wrote:
> Hi Bryan,
>
> Bryan Atsatt wrote:
>> ...
>> frameworks/libraries are precisely what a module system is for: to allow
>> their clients to *avoid* bundling the jars. And they aren't likely to be
>> deployed as extensions, either; not when there's this nice repository
>> model. Consider Spring. Or any of the hundreds of other third party
>> frameworks/libraries out there. We *want* these to be deployed as
>> normal, separate modules.
>
> I agreed. My point was that in many cases, these frameworks/libraries
> would be deployed into the repository and loaded with all permissions at
> runtime,

That last phrase seems like a huge leap to me. How exactly would this
grant all permissions? And, even if it did, it seems like an *extremely*
large security hole!

(But, again, I don't feel the need to dwell on the grant issue at the
moment--we have bigger fish to fry.)

> so this should not be an issue even they are deployed as
> normal, separate modules.
>
>> There is a much bigger issue, which is that this whole model falls apart
>> simply because we can't grant this type of "friend" access to module
>> private classes...
>>
>> Your description of how ResourceBundle or ServiceLoader accesses the
>> class contains a big assumption, one that *could* be correct for such
>> JRE code, but is almost certainly wrong for third-party code.
>>
>> These types of frameworks call Class.forName() or loader.loadClass().
>> And then they call either Class.newInstance() or
>> Constructor.newInstance().
>>
>> Regardless of whether or not they invoke any other methods, JSR 294 will
>> require an access control check at the point of instantiation, extending
>> those it performs today. Look at how Class.newInstance() and
>> Constructor.newInstance() both use:
>>
>>     Reflection.ensureMemberAccess()
>>
>> This is the logical point at which to inject the new module private
>> access control check.
>>
>> Could this be made to succeed for JRE callers? Of course (but it
>> wouldn't be right, IMO).
>>
>> But, more importantly: it won't, and cannot, succeed for third-party
>> callers without some sort of friend model for classes. Which isn't on
>> the table.
>>
>> So, again, if we're not going to do this for classes, why should we do
>> it for resources?
>
> Sorry, I still don't think I fully understand your point. From my
> perspective, the access model for exported classes and exported
> resources are orthogonal. I agreed that it would be nice to have some
> symmetries between them, but I think we already concluded why this is
> not feasible because of their fundamental differences. The fact that
> this is not how we support classes today doesn't mean we could not do it
> for resources.
>
> Perhaps it would help to pull out the following question you had couple
> emails back for our discussion:
>
> Bryan Atsatt wrote:
>  > 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?
>
> In today's model, if the resource is available, #1 will always succeed.
> If the provider class is available, then #3 will also succeed, and
> whether the class is accessible will be determined by the JVM. The
> entire "exported resources" issue is basically around the behavioral
> change in #1; this is orthogonal to #2 and #3, and I think we should
> ignore the entire "exported classes" issue for the moment to keep this
> discussion focus.
>
> That said, I realize that we might have been thinking about two very
> different use cases (correct me if I misunderstand you) here:
>
> a. Some service-related frameworks (e.g. ServiceLoader) need to retrieve
> resources like META-INF/services/<service-provider> from the module
> classloader.
> b. A module uses the ResourceBundle APIs to retrieve property-based
> resources or list-based resources from its own module.
>
> For (a) alone, I would agree with you that this kind of resource might
> simply be exported. In fact, I don't think this should even be
> considered a private resource because its content is intended for
> external consumption.
>
> For (b), I don't think it makes sense to require a module exporting the
> private resources for its own consumption, and this is where I hope the
> security permission approach would help to make it work.
>
> Suppose we say that resources like (a) should be exported while
> resources like (b) should remain private (and we'll use the security
> permission approach to allow module to access its own private
> resources), do you think you can live with this?

It isn't just me that can't live with it :^). You are correct that
private *property-based* resources could be retrieved this way, but
incorrect about *list-based* resources.

"List-based" resources are... *Class* instances. Specifically, they are
subclasses of ListResourceBundle. They must be loaded and instantiated
by ResourceBundle.

If ListResourceBundle subclasses are module private,
ResourceBundle.getBundle() will fail. And we have no mechanism to grant
access.

// Bryan

>
> - Stanley
>