FW: SecurityManager.checkPackageAccess for qualified exports

Sean Mullan sean.mullan at oracle.com
Fri May 12 15:01:55 UTC 2017


On 5/12/17 9:14 AM, Langer, Christoph wrote:
> Hi Sean,
> 
> thanks for your response.
> 
>>>
>>> *Implementation Note:***
>>>
>>> This implementation also restricts all non-exported packages of modules
>>> loaded bythe platform class loader
>>>
>> <http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#
>> getPlatformClassLoader-->or
>>> its ancestors. A "non-exported package" refers to a package that is not
>>> exported to all modules. Specifically, it refers to a package that
>>> either is not exported at all by its containing module or is exported in
>>> a qualified fashion by its containing module.
>>>
>>> Reading this, I'm wondering whether the implementation should implicitly
>>> grant package access for modules that a package in question was exported
>>> to in a qualified fashion? Now one ends up having to additionally add
>>> specific permissions which can easily be forgot.
>>
>> It was considered. In particular, the security permission check that is
>> done when loading classes of non-exported packages is essentially
>> equivalent to the module access check. However, in other package access
>> checking cases, the SecurityManager check does a full stack walk and
>> checks that every relevant ProtectionDomain on the stack has permission
>> to access the non-exported package. The module access check only checks
>> if the source module has access. There was some concern that this may
>> not be sufficient to guard against all possible attack scenarios.
> 
> I think the package access check walking down the whole stack is fine and should be done here, not just the module access check.
> 
> However, frames originating out of a module that the package was exported to should have the permission to access the package. Such that when I would run in a privileged section there, I would get package access. And if I wouldn't run privileged then all the calling frames would be checked and the check might not be passed. Wouldn't that be the right way?

Yes, I think something like this is worth considering but needs to be 
prototyped and carefully reviewed before we would be able to consider 
it. I can file an issue to track this, but in my opinion it is too late 
for JDK 9.

Thanks,
Sean



More information about the security-dev mailing list