On Thu, Sep 10, 2015 at 4:21 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> >> * Cleaning up a bunch of bad package accesses, these were already >> TODOs in our test security policy, mostly just test bugs and the like. > > "bad package accesses", do you mean direct use of JDK-internal classes? As > you mention security policy then I will guess that these must be granting of > accessClassInPackage.$PKG because the default policy when running with a > security manager does not allow direct access to sun.* APIs. > Yes, unfortunately when it comes to java libs this is "widespread" to say the least. When looking at the current situation for elasticsearch, as far as internal package usage, we aren't doing it ourselves, but today i've still got to worry about: 1. sun.misc.* for the mmap "unmap hack" of lucene. 2. sun.security.ssl.* for some crazy code in the AWS api. 3. sun.reflect.* for something groovy is doing. Its rare that java libraries use these internal packages in a "nice" way (e.g. well-contained in accesscontroller block, fallback if its not allowed/optional,. ...). Usually it is just direct usage and nobody is aware or cares about it, because most people are not using securitymanager. Third party developers don't seem to care when you throw the securitymanager argument at them, e.g. i've raised #2 with AWS months ago and nobody has done anything. So I am happy to see this stuff enforced more by jigsaw, because it gives me a stronger argument than my current screaming "this is really screwed up, its a security problem, etc". The downside is I do know a lot of code/libraries has issues like this, because I've been trying to whittle down the security permissions for this crazy stuff for months. That's why I think it will impact a lot of developers: I am sure lots of code does stuff like integrate with AWS, or integrate scripting languages like groovy, etc. Its harder to fix when its a dependency.
