jigsaw EA feedback for apache lucene

[Robert Muir]

On Thu, Sep 10, 2015 at 4:21 AM, Alan Bateman <Alan.Bateman at 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.