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
