Hi,
> On 26/01/2016 14:05, Uwe Schindler wrote:
> > Hi,
> >
> > looks good to me. Once we have EA builds with that I will adapt the
> ByteBufferIndexInput code in Lucene.
> >
> > One thing about the Runable: This should work perfectly fine, because we
> only need to make call the getCleaner() method accessible, call it and finally
> check if return type implements Runable (if not we fall back to pre Java 9
> code). We can then cast and invoke the cleaner without any further
> reflection.
> >
> > But there is now some security related issue: The reflection on DirectBuffer
> should work in most environments (also with security managers), so you can
> get the Cleaner instance with a doPrivileged (ideally). But as this cleaner
> instance was previously inside sun.misc package, and you needed
> RuntimePermission "accessInPackage.sun.misc" to call and make the clean
> method accessible. But with the new patch you no longer need this
> permission, making it easier to invoke that method.
> >
> This is a private field so if you are hacking into it then you'll need
> ReflectPermission("suppressAccessChecks") when running with a security
> manager. Clearly anything with a reference to a Cleaner needs to be
> super careful not to let it leak to untrusted code.
I know and Lucene takes care of that.
I just said, previously you needed both runtime permissions:
"accessInPackage.sun.misc" AND "suppressAccessChecks", now only one. I just
suggested to add the 2nd hurdle back somehow, as additional safety.
Otherwise I am fine with the patch, was just meant as "improvement". E.g.,
Elasticsearch already gives *only* lucene-core.jar both permisisions, nothing
else in its code!!!
Uwe
