Standalone Nashorn is coming for Java 15+

[Attila Szegedi]

> On 2020. Oct 12., at 19:19, Gustavo Lopes <gustavo at sqreen.com> wrote:
> 
> On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi <szegedia at gmail.com> wrote:
>> 
>> On 2020. Oct 12., at 18:41, Gustavo Lopes <gustavo at sqreen.com> wrote:
>>> 
>>> * Half a dozen sandboxing tests don't pass because they require that nashorn be loaded on the platform classloader. More precisly, when running with a security manager and with -Djava.security.properties= pointing to a file restricting class loading with package.access, it seems to rely on the fact that the platform classloader doesn't have the call to SecurityManager::checkPackageAccess that the app classloader has
>> 
>> I have maybe 9 test failures in my current working copy, but yeah, the checkPackageAccess issue exists. It also can just be a red herring of there being an explicit addition of Nashorn internal packages to access-checked list. I’ve been trying to figure out what to do about that.
> 
> To be clear, the failing tests are just these four:
> 
> https://github.com/sqreen/nashorn/tree/master/test/nashorn/script/failing-sandboxing

That’s funny, I re-checked and I also only have exactly those same 4 :-) 9 was probably an older number from early this weekend.

> I'm not sure what to do with these. I think what's going on that when
> Nashorn classes attempt to load classes from the internal package
> (after limiting access in the internal package via package.access=),
> they are not blocked because nashorn is loaded on the platform
> classloader (but when a script attempts to explicitly load internal
> classes it is blocked, because the scripts use a different
> classloader). Check the definitions of the Platform and App
> classloaders in Classloaders.java — only the AppClassloader calls
> SecurityManager::checkPackageAccess. But Java only loads on the
> platform classloader a hardcoded list of modules, so we go to the app
> classloader now. Maybe this can be worked around by tuning the policy
> file with extra accessClassInPackage permissions but I didn't manage
> to get it working in the alloted time.

Yeah, I’ve been wondering if we need that “package.access=“ It used to be there to ensure in code that client code can’t access Nashorn internals. Now that Nashorn is no longer running as privileged JDK code, this might not even be needed. I actually asked Sundar earlier today about this, we’ll keep thinking about what would be the valid way forward.

It’s great that you’ve gotten to this point too!

Attila.