Re: Exported resources
(resend) No problem, tackle these however you want. I've just had some time and have taken the opportunity to air out some of the ideas that have been lurking in my brain... // Bryan Stanley M. Ho wrote: Hi Bryan, I would like to have some closures on the older threads first before responding to the newly created ones, so don't take my silent as ignoring those new threads. ;-) Bryan Atsatt wrote: Whoops, .jsp files are not candidates for private resources, since the *container* must have access to them. But I stand by the gif/html/xml comment :^). Another candidate is property files (thanks to Stephen McConnell for reminding me), when used as default configuration. In the context of the EE environment, my question is that who exactly are we trying to protect these resources from? If the answer is the container, making these resources public would also be acceptable 'cause I don't think we expect the container would mess around these resources if they remain public. Based on what we discussed so far, my impression is that we can implement the notion of "private resources" but it won't solve the general cases like ResourceBundle; having the notion of "private resources" would be nice-to-have in some cases, but they are not critical. I think we have dragged on this thread for too long. Perhaps a way out is to go with the simple notion of exported-means-visible-and-accessible for now (i.e. exported resources are visible and accessible by everyone, non-exported are visible and accessible by nobody). We could revisit this issue around "private resources" after we gather more feedbacks when the updated specification is published. What do you think? - Stanley
Re: Exported resources
Hi Bryan, I would like to have some closures on the older threads first before responding to the newly created ones, so don't take my silent as ignoring those new threads. ;-) Bryan Atsatt wrote: Whoops, .jsp files are not candidates for private resources, since the *container* must have access to them. But I stand by the gif/html/xml comment :^). Another candidate is property files (thanks to Stephen McConnell for reminding me), when used as default configuration. In the context of the EE environment, my question is that who exactly are we trying to protect these resources from? If the answer is the container, making these resources public would also be acceptable 'cause I don't think we expect the container would mess around these resources if they remain public. Based on what we discussed so far, my impression is that we can implement the notion of "private resources" but it won't solve the general cases like ResourceBundle; having the notion of "private resources" would be nice-to-have in some cases, but they are not critical. I think we have dragged on this thread for too long. Perhaps a way out is to go with the simple notion of exported-means-visible-and-accessible for now (i.e. exported resources are visible and accessible by everyone, non-exported are visible and accessible by nobody). We could revisit this issue around "private resources" after we gather more feedbacks when the updated specification is published. What do you think? - Stanley
Re: Exported resources
Whoops, .jsp files are not candidates for private resources, since the
*container* must have access to them. But I stand by the gif/html/xml
comment :^).
Another candidate is property files (thanks to Stephen McConnell for
reminding me), when used as default configuration.
Bryan Atsatt wrote:
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Yes, I think we're getting close now :^)
(By "privileged reflection", you mean having permission to call
AccessibleObject.setAccessible(true), right? If so, then we're back to
the grant issue!)
Yes. In this case, it's the ResourceBundle API calling it to retrieve
ListResourceBundle, so it'll have the sufficient permissions to do that.
Anyway, I think we should leave this issue aside for now.
I still think we can provide "private", (i.e. non-exported) resources
which *are* available to the module classes, but to no class outside
of it.
Without using permissions.
Remember this?
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
If a resource is found, and is not-exported, a module class loader can
use this (or similar) to get the immediate caller's class (at a fixed
index).
If the caller class' Module does not match that for the loader, we don't
return the resource.
I think we should step back to rethink the use cases a bit.
Typically, a module calls some APIs (e.g. ResourceBundle, AWTToolkit,
etc.) and these APIs might then retrieve resources through the module's
ClassLoader.getResource*(). If we are saying that a module is required
to make these resources exported in order for these use cases to work,
then what are the actual use cases we want to support by hiding
resources from getResource*()?
I think there remains a common use case where hiding resources would be
a good thing if developers want to hide all the resources that are not
used by anyone through ClassLoader.getResource*() (e.g. all the .class
files). On the other hand, I think the use case where the code in the
module calls its own ClassLoader.getResource*() to retrieve private
resources directly is not very common; If this is a rare use case, I
don't think it makes sense to introduce this notion of "private
resources". If we are forcing developers to export resources for the
common use cases (like ResourceBundle and ServiceLoader) anyway, then
why not require them to export resources in other cases as well?
It would help if there are some real use cases to support why it is
important to have this notion of "private resources".
One very common use case comes from the EE world: web modules containing
html/gif/xml/jsp files, all of which are implementation details.
I would assume that most any app with a UI would have similar resources.
- Stanley
Re: Exported resources
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Yes, I think we're getting close now :^)
(By "privileged reflection", you mean having permission to call
AccessibleObject.setAccessible(true), right? If so, then we're back to
the grant issue!)
Yes. In this case, it's the ResourceBundle API calling it to retrieve
ListResourceBundle, so it'll have the sufficient permissions to do that.
Anyway, I think we should leave this issue aside for now.
I still think we can provide "private", (i.e. non-exported) resources
which *are* available to the module classes, but to no class outside
of it.
Without using permissions.
Remember this?
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
If a resource is found, and is not-exported, a module class loader can
use this (or similar) to get the immediate caller's class (at a fixed
index).
If the caller class' Module does not match that for the loader, we don't
return the resource.
I think we should step back to rethink the use cases a bit.
Typically, a module calls some APIs (e.g. ResourceBundle, AWTToolkit,
etc.) and these APIs might then retrieve resources through the module's
ClassLoader.getResource*(). If we are saying that a module is required
to make these resources exported in order for these use cases to work,
then what are the actual use cases we want to support by hiding
resources from getResource*()?
I think there remains a common use case where hiding resources would be
a good thing if developers want to hide all the resources that are not
used by anyone through ClassLoader.getResource*() (e.g. all the .class
files). On the other hand, I think the use case where the code in the
module calls its own ClassLoader.getResource*() to retrieve private
resources directly is not very common; If this is a rare use case, I
don't think it makes sense to introduce this notion of "private
resources". If we are forcing developers to export resources for the
common use cases (like ResourceBundle and ServiceLoader) anyway, then
why not require them to export resources in other cases as well?
It would help if there are some real use cases to support why it is
important to have this notion of "private resources".
One very common use case comes from the EE world: web modules containing
html/gif/xml/jsp files, all of which are implementation details.
I would assume that most any app with a UI would have similar resources.
- Stanley
Re: Exported resources
Hi Bryan,
Bryan Atsatt wrote:
Yes, I think we're getting close now :^)
(By "privileged reflection", you mean having permission to call
AccessibleObject.setAccessible(true), right? If so, then we're back to
the grant issue!)
Yes. In this case, it's the ResourceBundle API calling it to retrieve
ListResourceBundle, so it'll have the sufficient permissions to do that.
Anyway, I think we should leave this issue aside for now.
I still think we can provide "private", (i.e. non-exported) resources
which *are* available to the module classes, but to no class outside of it.
Without using permissions.
Remember this?
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
If a resource is found, and is not-exported, a module class loader can
use this (or similar) to get the immediate caller's class (at a fixed
index).
If the caller class' Module does not match that for the loader, we don't
return the resource.
I think we should step back to rethink the use cases a bit.
Typically, a module calls some APIs (e.g. ResourceBundle, AWTToolkit,
etc.) and these APIs might then retrieve resources through the module's
ClassLoader.getResource*(). If we are saying that a module is required
to make these resources exported in order for these use cases to work,
then what are the actual use cases we want to support by hiding
resources from getResource*()?
I think there remains a common use case where hiding resources would be
a good thing if developers want to hide all the resources that are not
used by anyone through ClassLoader.getResource*() (e.g. all the .class
files). On the other hand, I think the use case where the code in the
module calls its own ClassLoader.getResource*() to retrieve private
resources directly is not very common; If this is a rare use case, I
don't think it makes sense to introduce this notion of "private
resources". If we are forcing developers to export resources for the
common use cases (like ResourceBundle and ServiceLoader) anyway, then
why not require them to export resources in other cases as well?
It would help if there are some real use cases to support why it is
important to have this notion of "private resources".
- Stanley
Re: Exported resources
Yes, I think we're getting close now :^)
(By "privileged reflection", you mean having permission to call
AccessibleObject.setAccessible(true), right? If so, then we're back to
the grant issue!)
I still think we can provide "private", (i.e. non-exported) resources
which *are* available to the module classes, but to no class outside of it.
Without using permissions.
Remember this?
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
If a resource is found, and is not-exported, a module class loader can
use this (or similar) to get the immediate caller's class (at a fixed
index).
If the caller class' Module does not match that for the loader, we don't
return the resource.
Which is what I did in the prototype.
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
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.
Oops... I missed that. ;-)
If ListResourceBundle subclasses are module private,
ResourceBundle.getBundle() will fail. And we have no mechanism to grant
access.
If some class needs access to non-public/exported details of another
class, you can always use privileged reflection. That is the solution
today and I expect it will be available with superpackages too. In other
words, it is possible for ResourceBundle.getBundle() to succeed. Of
course, it is still debatable whether changing ResourceBundle to use
privileged reflection to access ListResourceBundle in a module is the
right thing to do.
I think I begin to see your point. To elaborate on what you said, if
ListResourceBundle must be made exported, then it probably makes sense
to require property-based resources to be exported from the module as
well. If we go down this path, then all resources that are accessible by
the module itself or other modules should be made exported, and it won't
require the security permission approach to support it. Actually,
calling it "exported resource" would be misleading; what it really means
is "public resource" or "accessible resource" which can be accessed by
anyone, but nobody could access the "private resource" including the
module itself.
- Stanley
Re: Exported resources
Hi Bryan, Bryan Atsatt wrote: 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. Oops... I missed that. ;-) If ListResourceBundle subclasses are module private, ResourceBundle.getBundle() will fail. And we have no mechanism to grant access. If some class needs access to non-public/exported details of another class, you can always use privileged reflection. That is the solution today and I expect it will be available with superpackages too. In other words, it is possible for ResourceBundle.getBundle() to succeed. Of course, it is still debatable whether changing ResourceBundle to use privileged reflection to access ListResourceBundle in a module is the right thing to do. I think I begin to see your point. To elaborate on what you said, if ListResourceBundle must be made exported, then it probably makes sense to require property-based resources to be exported from the module as well. If we go down this path, then all resources that are accessible by the module itself or other modules should be made exported, and it won't require the security permission approach to support it. Actually, calling it "exported resource" would be misleading; what it really means is "public resource" or "accessible resource" which can be accessed by anyone, but nobody could access the "private resource" including the module itself. - Stanley
Re: Exported resources
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/ 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-b
Re: Exported resources
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, 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/ 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? - Stanley
Re: Exported resources
Hey Stanley, Yeah, sorry about the flood of mail; I've had a little time to catch up. You seem to have a JRE-centric perspective here ;^). Third-party 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. And signing a jar by itself doesn't grant any additional permissions, it simply enables verification of the contained classes. Some environments may support UI to grant additional permissions, of course, but that is orthogonal. But, lets leave aside the whole grant issue for now, and assume that we can grant permissions as needed to access module private resources. 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? // Bryan Stanley M. Ho wrote: Hi Bryan, I would like to get closures on a few open issues first, so my responses will be limited to those threads rather than all the new threads that have been started recently. Bryan Atsatt wrote: Hi Stanley, Sorry if I'm not being clear. Let me try to summarize: - I *do* want 277 to support private (non-exported) resources, but Good. - I do not think we should use permissions as the enforcement mechanism. - I believe the 'caller-class-is-member' enforcement mechanism is sufficient, and - I do realize that this means ResourceBundle.getBundle() (or similar) will fail to find private resources; these must be made public. Let me give more detailed reasoning for this position... You are of course correct that a class loader is free to add permissions to any class by assigning a ProtectionDomain with those permissions during defineClass(). (Let's call these "hard-wired" permissions.) So permission to access private resources could easily be hard-wired for other classes *in the same module*. To this point, there really isn't any meaningful difference between using permissions or using my approach: both allow module classes to directly access their private resources. But if we want to grant that same permission to *any* class outside of the module, it gets far more interesting. And it is this problem that I'm concerned with. For ResourceBundle.getBundle(), for example, to access a private resource, we must grant permission to the *ResourceBundle* class. And how do we do that? We could hard-wire permission for ResourceBundle, but... what about ServiceLoader? Ok, so let's just hard-wire permission for any JRE module. The system classes are granted with all permissions, so they will have sufficient permissions to access the private resources in a module. I don't think this is a real issue. Problem solved? Not at all: what about all the non JRE frameworks out in the world that need the same kind of access? I agreed that using other frameworks might be a concern. Clearly we cannot hard-wire permissions for these. So now we need to use policy file entries to do so. We could of course take this approach, but it either leaves some poor admin running around to update policy files as things break, or some fancy mechanism to grant access during framework module install. Ick. If the framework is bundled as part of your module, it will have the same set of permissions as the other code in your module, so it will have sufficient permissions to allow your code to access the private resources. If the framework is deployed through the typical mechanisms (e.g. extension classpath, etc.), it will have all permissions, hence it will also have sufficient permissions to access the private resources. Further, if the framework is deployed as another module in one of the system's repositories, it wi
Re: Exported resources
Hi Bryan, I would like to get closures on a few open issues first, so my responses will be limited to those threads rather than all the new threads that have been started recently. Bryan Atsatt wrote: Hi Stanley, Sorry if I'm not being clear. Let me try to summarize: - I *do* want 277 to support private (non-exported) resources, but Good. - I do not think we should use permissions as the enforcement mechanism. - I believe the 'caller-class-is-member' enforcement mechanism is sufficient, and - I do realize that this means ResourceBundle.getBundle() (or similar) will fail to find private resources; these must be made public. Let me give more detailed reasoning for this position... You are of course correct that a class loader is free to add permissions to any class by assigning a ProtectionDomain with those permissions during defineClass(). (Let's call these "hard-wired" permissions.) So permission to access private resources could easily be hard-wired for other classes *in the same module*. To this point, there really isn't any meaningful difference between using permissions or using my approach: both allow module classes to directly access their private resources. But if we want to grant that same permission to *any* class outside of the module, it gets far more interesting. And it is this problem that I'm concerned with. For ResourceBundle.getBundle(), for example, to access a private resource, we must grant permission to the *ResourceBundle* class. And how do we do that? We could hard-wire permission for ResourceBundle, but... what about ServiceLoader? Ok, so let's just hard-wire permission for any JRE module. The system classes are granted with all permissions, so they will have sufficient permissions to access the private resources in a module. I don't think this is a real issue. Problem solved? Not at all: what about all the non JRE frameworks out in the world that need the same kind of access? I agreed that using other frameworks might be a concern. Clearly we cannot hard-wire permissions for these. So now we need to use policy file entries to do so. We could of course take this approach, but it either leaves some poor admin running around to update policy files as things break, or some fancy mechanism to grant access during framework module install. Ick. If the framework is bundled as part of your module, it will have the same set of permissions as the other code in your module, so it will have sufficient permissions to allow your code to access the private resources. If the framework is deployed through the typical mechanisms (e.g. extension classpath, etc.), it will have all permissions, hence it will also have sufficient permissions to access the private resources. Further, if the framework is deployed as another module in one of the system's repositories, it will likely have all permissions to allow your code to access the private resources in your module as well. Moreover, if the framework JAR/module is signed and is trusted, the system will typically grant all permissions to the code in the framework when the code is loaded. In other words, there is no need to explicitly grant permissions in most scenarios. The scenario where this may be an issue is when the framework is deployed through some other means (e.g. other modules in a URLRepository, JARs in custom classloaders) *and* the framework is unsigned (or if the framework is signed but not trusted for some reasons), it may not have sufficient permissions to allow your code to access the private resources through the framework API. However, it is unclear to me if there are frameworks deployed like this for this issue to become a real problem. Do you have any example that shows this is a real problem? And, hard-wired or not, permissions *are* a friend model. But 294 is not likely to provide such a model for classes. So, even if we hard-wire permission for ResourceBundle to access a private resource, how is it going to access a private ListResourceBundle class? Or how will the ServiceLoader gain access to the service provider class? How will third-party frameworks solve this problem? In a typical classloader, all public and private classes are visible (return from loadClass()) externally but only the public ones are accessible (invoke without access control failure). When a module uses the ResourceBundle API to load the ListResourceBundle from the module itself, the ResourceBundle API only loads the class from the module classloader and the class is returned to the code in the module for actual access. ServiceLoader works in similar way that the ServiceLoader only loads the service-provider class but it's the actual caller who accesses the class. Therefore, I don't think there is a real problem here. It is hard for me to see how all this complexity is justified, simply to hide resources that have never been hidden before. This doesn't mean there is no place for private resources! It just means that they ca
Re: Exported resources
Hi Stanley, Sorry if I'm not being clear. Let me try to summarize: - I *do* want 277 to support private (non-exported) resources, but - I do not think we should use permissions as the enforcement mechanism. - I believe the 'caller-class-is-member' enforcement mechanism is sufficient, and - I do realize that this means ResourceBundle.getBundle() (or similar) will fail to find private resources; these must be made public. Let me give more detailed reasoning for this position... You are of course correct that a class loader is free to add permissions to any class by assigning a ProtectionDomain with those permissions during defineClass(). (Let's call these "hard-wired" permissions.) So permission to access private resources could easily be hard-wired for other classes *in the same module*. To this point, there really isn't any meaningful difference between using permissions or using my approach: both allow module classes to directly access their private resources. But if we want to grant that same permission to *any* class outside of the module, it gets far more interesting. And it is this problem that I'm concerned with. For ResourceBundle.getBundle(), for example, to access a private resource, we must grant permission to the *ResourceBundle* class. And how do we do that? We could hard-wire permission for ResourceBundle, but... what about ServiceLoader? Ok, so let's just hard-wire permission for any JRE module. Problem solved? Not at all: what about all the non JRE frameworks out in the world that need the same kind of access? Clearly we cannot hard-wire permissions for these. So now we need to use policy file entries to do so. We could of course take this approach, but it either leaves some poor admin running around to update policy files as things break, or some fancy mechanism to grant access during framework module install. Ick. And, hard-wired or not, permissions *are* a friend model. But 294 is not likely to provide such a model for classes. So, even if we hard-wire permission for ResourceBundle to access a private resource, how is it going to access a private ListResourceBundle class? Or how will the ServiceLoader gain access to the service provider class? How will third-party frameworks solve this problem? It is hard for me to see how all this complexity is justified, simply to hide resources that have never been hidden before. This doesn't mean there is no place for private resources! It just means that they can only be used by the module classes themselves. And this is still a very valuable feature: developers can restrict access to resources that are strictly implementation details. // Bryan Stanley M. Ho wrote: 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
Re: Exported resources
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
Re: Exported resources
I don't think I'm missing anything, just looking at it from perhaps a
different perspective :^)
First, 294 will determine accessibility for non-exported classes. The
assumption at the moment is that they will not be accessible to *any*
class outside of the module.
I do understand the value of a "friend" semantic; it would certainly be
nice to grant certain frameworks special access. But, so far, that is
not on the table for classes.
And if we don't have it for classes, I can't see why we should have it
for resources.
// Bryan
Glyn Normington wrote:
Some feedback from an observer which may help:
> Bryan misses the need for extender model to load internal impl
classes ala
> Bundle.loadClass in OSGi.
>
> You do not want to have to export the service impl class from a module.
> You want to hide the class from others' casual loading. However an
> extender bundle (e.g. ServiceLoader) will need to be able to load that
> class to make it instances of it available to others under the service
> interface class.
Glyn
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 21:21:36:
> I've been assuming that Module private resources should not be visible
> to *any* class outside of the module. Including ResourceBundle, or any
> other existing framework classes that do resource lookups (e.g.
> ServiceLoader, JSF, etc). If resources need to be visible to these
> existing classes, they must be exported. The very simple check I
> proposed (immediate caller) is sufficient to make this assertion.
>
> I believe your point is that if we used the permission model instead, it
> would become possible for a module to invoke an external class (e.g.
> ResourceBundle.getBundle()) and enable *it* to successfully load a
> private resource from the module.
>
> Aside from the permission *grant* mechanism this model would rely on, it
> is an entirely different model than that used for classes! (Though we
> haven't explicitly defined this in 294, it seems extremely unlikely that
> we will rely on permissions--none of the other access modes do so.) Such
> asymmetry is very disconcerting to me, and, I believe, just plain
wrong...
>
> Consider that you could grant the ServiceLoader, for example, access to
> a resource that names a class that it could not instantiate. That class
> would have to be exported. I believe the resource should be as well.
>
> // Bryan
>
>
>
>
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > Those resource-related methods in ClassLoader can be called by anyone,
> > including code that is part of the module, code that is from other
> > modules, or code that is part of the platform libraries (e.g.
> > ResourceBundle). The approach you described would require walking the
> > stack to get the caller's Module, but the real issue is that it is
> > difficult to determine who the actual caller is from the stack.
> >
> > Treating the immediate caller on the stack as the actual caller
wouldn't
> > be sufficient because the immediate caller could be called by someone
> > else who is the one actually making the call. On the other hand,
> > treating the originated caller on the stack as the actual caller would
> > be the right semantic, but this is basically the same as the security
> > permission approach.
> >
> > - Stanley
> >
> >
> > Bryan Atsatt wrote:
> >> Both solutions require stack walking (unless there is some new
> >> implementation of the java security model I've not yet seen!).
> >>
> >> The permission check does much more work than is necessary here.
Take a
> >> look at AccessController.checkPermission() to see what I mean.
> >>
> >> And actually there is a very simple API to get the stack, which I've
> >> used for years:
> >>
> >> private static class StackAccessor extends SecurityManager {
> >> public Class[] getStack() {
> >> return getClassContext();
> >> }
> >> }
> >>
> >> private static final STACK_ACCESSOR = new StackAccessor();
> >>
> >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
> >>
> >> // Bryan
> >>
> >>
> >>
> >> Stanley M. Ho wrote:
> >>> Hi Bryan,
> >>>
> >>> Bryan Atsatt wrote:
> 1. Definitely agree that resource search order should be
identical to
> class search order.
> >>>
> >>> Glad to hear!
> >>>
> 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.
> >>>
> >>> The issue is that this approach still requires stack walking and
there
> >>> is no public API in the SE platform that let you implement this.
> >>>
> >>> If stack walking is required for the check anyway, I think the
security
> >>> permission approach is better tha
Re: Exported resources
Some feedback from an observer which may help:
> Bryan misses the need for extender model to load internal impl classes
ala
> Bundle.loadClass in OSGi.
>
> You do not want to have to export the service impl class from a module.
> You want to hide the class from others' casual loading. However an
> extender bundle (e.g. ServiceLoader) will need to be able to load that
> class to make it instances of it available to others under the service
> interface class.
Glyn
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 30/05/2007 21:21:36:
> I've been assuming that Module private resources should not be visible
> to *any* class outside of the module. Including ResourceBundle, or any
> other existing framework classes that do resource lookups (e.g.
> ServiceLoader, JSF, etc). If resources need to be visible to these
> existing classes, they must be exported. The very simple check I
> proposed (immediate caller) is sufficient to make this assertion.
>
> I believe your point is that if we used the permission model instead, it
> would become possible for a module to invoke an external class (e.g.
> ResourceBundle.getBundle()) and enable *it* to successfully load a
> private resource from the module.
>
> Aside from the permission *grant* mechanism this model would rely on, it
> is an entirely different model than that used for classes! (Though we
> haven't explicitly defined this in 294, it seems extremely unlikely that
> we will rely on permissions--none of the other access modes do so.) Such
> asymmetry is very disconcerting to me, and, I believe, just plain
wrong...
>
> Consider that you could grant the ServiceLoader, for example, access to
> a resource that names a class that it could not instantiate. That class
> would have to be exported. I believe the resource should be as well.
>
> // Bryan
>
>
>
>
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > Those resource-related methods in ClassLoader can be called by anyone,
> > including code that is part of the module, code that is from other
> > modules, or code that is part of the platform libraries (e.g.
> > ResourceBundle). The approach you described would require walking the
> > stack to get the caller's Module, but the real issue is that it is
> > difficult to determine who the actual caller is from the stack.
> >
> > Treating the immediate caller on the stack as the actual caller
wouldn't
> > be sufficient because the immediate caller could be called by someone
> > else who is the one actually making the call. On the other hand,
> > treating the originated caller on the stack as the actual caller would
> > be the right semantic, but this is basically the same as the security
> > permission approach.
> >
> > - Stanley
> >
> >
> > Bryan Atsatt wrote:
> >> Both solutions require stack walking (unless there is some new
> >> implementation of the java security model I've not yet seen!).
> >>
> >> The permission check does much more work than is necessary here. Take
a
> >> look at AccessController.checkPermission() to see what I mean.
> >>
> >> And actually there is a very simple API to get the stack, which I've
> >> used for years:
> >>
> >> private static class StackAccessor extends SecurityManager {
> >> public Class[] getStack() {
> >> return getClassContext();
> >> }
> >> }
> >>
> >> private static final STACK_ACCESSOR = new StackAccessor();
> >>
> >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
> >>
> >> // Bryan
> >>
> >>
> >>
> >> Stanley M. Ho wrote:
> >>> Hi Bryan,
> >>>
> >>> Bryan Atsatt wrote:
> 1. Definitely agree that resource search order should be identical
to
> class search order.
> >>>
> >>> Glad to hear!
> >>>
> 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.
> >>>
> >>> The issue is that this approach still requires stack walking and
there
> >>> is no public API in the SE platform that let you implement this.
> >>>
> >>> If stack walking is required for the check anyway, I think the
security
> >>> permission approach is better that it is implementable with the
existing
> >>> API in the SE platform.
> >>>
> >>> - Stanley
> >>>
> >
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Exported resources
Hey Stanley, Sorry to be generating so much traffic while you're traveling! I'm not in any rush here, so feel free to take your time responding... Stanley M. Ho wrote: Hi Bryan, A module can use the ResourceBundle API to retrieve resources from other resource modules, but it can also use the ResourceBundle API to retrieve resources from the (target) module itself. In the latter case, the resources are currently not required to be exported from the target module. I don't think we want to force a module to export its own private resources simply because it wants to use the ResourceBundle API in this case, would you agree? 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 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? Regarding there are differences in the access models between classes and resources, I also prefer symmetry if possible. However, the access model for classes and resources have always been different, and there are built-in JVM support for classes while there is none for resources, so it is unclear if we can completely eliminate this asymmetry after all. 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 - Stanley Bryan Atsatt wrote: I've been assuming that Module private resources should not be visible to *any* class outside of the module. Including ResourceBundle, or any other existing framework classes that do resource lookups (e.g. ServiceLoader, JSF, etc). If resources need to be visible to these existing classes, they must be exported. The very simple check I proposed (immediate caller) is sufficient to make this assertion. I believe your point is that if we used the permission model instead, it would become possible for a module to invoke an external class (e.g. ResourceBundle.getBundle()) and enable *it* to successfully load a private resource from the module. Aside from the permission *grant* mechanism this model would rely on, it is an entirely different model than that used for classes! (Though we haven't explicitly defined this in 294, it seems extremely unlikely that we will rely on permissions--none of the other access modes do so.) Such asymmetry is very disconcerting to me, and, I believe, just plain wrong... Consider that you could grant the ServiceLoader, for example, access to a resource that names a class that it could not instantiate. That class would have to be exported. I believe the resource should be as well. // Bryan
Re: Exported resources
Hi Bryan, A module can use the ResourceBundle API to retrieve resources from other resource modules, but it can also use the ResourceBundle API to retrieve resources from the (target) module itself. In the latter case, the resources are currently not required to be exported from the target module. I don't think we want to force a module to export its own private resources simply because it wants to use the ResourceBundle API in this case, would you agree? Regarding there are differences in the access models between classes and resources, I also prefer symmetry if possible. However, the access model for classes and resources have always been different, and there are built-in JVM support for classes while there is none for resources, so it is unclear if we can completely eliminate this asymmetry after all. - Stanley Bryan Atsatt wrote: I've been assuming that Module private resources should not be visible to *any* class outside of the module. Including ResourceBundle, or any other existing framework classes that do resource lookups (e.g. ServiceLoader, JSF, etc). If resources need to be visible to these existing classes, they must be exported. The very simple check I proposed (immediate caller) is sufficient to make this assertion. I believe your point is that if we used the permission model instead, it would become possible for a module to invoke an external class (e.g. ResourceBundle.getBundle()) and enable *it* to successfully load a private resource from the module. Aside from the permission *grant* mechanism this model would rely on, it is an entirely different model than that used for classes! (Though we haven't explicitly defined this in 294, it seems extremely unlikely that we will rely on permissions--none of the other access modes do so.) Such asymmetry is very disconcerting to me, and, I believe, just plain wrong... Consider that you could grant the ServiceLoader, for example, access to a resource that names a class that it could not instantiate. That class would have to be exported. I believe the resource should be as well. // Bryan
Re: Exported resources
I've been assuming that Module private resources should not be visible
to *any* class outside of the module. Including ResourceBundle, or any
other existing framework classes that do resource lookups (e.g.
ServiceLoader, JSF, etc). If resources need to be visible to these
existing classes, they must be exported. The very simple check I
proposed (immediate caller) is sufficient to make this assertion.
I believe your point is that if we used the permission model instead, it
would become possible for a module to invoke an external class (e.g.
ResourceBundle.getBundle()) and enable *it* to successfully load a
private resource from the module.
Aside from the permission *grant* mechanism this model would rely on, it
is an entirely different model than that used for classes! (Though we
haven't explicitly defined this in 294, it seems extremely unlikely that
we will rely on permissions--none of the other access modes do so.) Such
asymmetry is very disconcerting to me, and, I believe, just plain wrong...
Consider that you could grant the ServiceLoader, for example, access to
a resource that names a class that it could not instantiate. That class
would have to be exported. I believe the resource should be as well.
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Those resource-related methods in ClassLoader can be called by anyone,
including code that is part of the module, code that is from other
modules, or code that is part of the platform libraries (e.g.
ResourceBundle). The approach you described would require walking the
stack to get the caller's Module, but the real issue is that it is
difficult to determine who the actual caller is from the stack.
Treating the immediate caller on the stack as the actual caller wouldn't
be sufficient because the immediate caller could be called by someone
else who is the one actually making the call. On the other hand,
treating the originated caller on the stack as the actual caller would
be the right semantic, but this is basically the same as the security
permission approach.
- Stanley
Bryan Atsatt wrote:
Both solutions require stack walking (unless there is some new
implementation of the java security model I've not yet seen!).
The permission check does much more work than is necessary here. Take a
look at AccessController.checkPermission() to see what I mean.
And actually there is a very simple API to get the stack, which I've
used for years:
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
Now the enclosing class can simply call STACK_ACCESSOR.getStack().
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
1. Definitely agree that resource search order should be identical to
class search order.
Glad to hear!
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.
The issue is that this approach still requires stack walking and there
is no public API in the SE platform that let you implement this.
If stack walking is required for the check anyway, I think the security
permission approach is better that it is implementable with the existing
API in the SE platform.
- Stanley
Re: Exported resources
Hi Bryan,
Those resource-related methods in ClassLoader can be called by anyone,
including code that is part of the module, code that is from other
modules, or code that is part of the platform libraries (e.g.
ResourceBundle). The approach you described would require walking the
stack to get the caller's Module, but the real issue is that it is
difficult to determine who the actual caller is from the stack.
Treating the immediate caller on the stack as the actual caller wouldn't
be sufficient because the immediate caller could be called by someone
else who is the one actually making the call. On the other hand,
treating the originated caller on the stack as the actual caller would
be the right semantic, but this is basically the same as the security
permission approach.
- Stanley
Bryan Atsatt wrote:
Both solutions require stack walking (unless there is some new
implementation of the java security model I've not yet seen!).
The permission check does much more work than is necessary here. Take a
look at AccessController.checkPermission() to see what I mean.
And actually there is a very simple API to get the stack, which I've
used for years:
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
Now the enclosing class can simply call STACK_ACCESSOR.getStack().
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
1. Definitely agree that resource search order should be identical to
class search order.
Glad to hear!
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.
The issue is that this approach still requires stack walking and there
is no public API in the SE platform that let you implement this.
If stack walking is required for the check anyway, I think the security
permission approach is better that it is implementable with the existing
API in the SE platform.
- Stanley
Re: Exported resources
Both solutions require stack walking (unless there is some new
implementation of the java security model I've not yet seen!).
The permission check does much more work than is necessary here. Take a
look at AccessController.checkPermission() to see what I mean.
And actually there is a very simple API to get the stack, which I've
used for years:
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
Now the enclosing class can simply call STACK_ACCESSOR.getStack().
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
1. Definitely agree that resource search order should be identical to
class search order.
Glad to hear!
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.
The issue is that this approach still requires stack walking and there
is no public API in the SE platform that let you implement this.
If stack walking is required for the check anyway, I think the security
permission approach is better that it is implementable with the existing
API in the SE platform.
- Stanley
Re: Exported resources
Hi Bryan, Bryan Atsatt wrote: 1. Definitely agree that resource search order should be identical to class search order. Glad to hear! 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. The issue is that this approach still requires stack walking and there is no public API in the SE platform that let you implement this. If stack walking is required for the check anyway, I think the security permission approach is better that it is implementable with the existing API in the SE platform. - Stanley
Re: Exported resources
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
