Standalone Nashorn is coming for Java 15+

[Gustavo Lopes]

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

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.

> > Most of the work was moving to gradle. I didn't have to make a lot of changes to the codebase. I had to change to the Unsafe in sun.misc rather than the internal one, to change the parent module layer for the scripting JPMS module created at runtime for when nashorn isn't loaded on the boot layer, then some tests required small tweaks but I don't remember much else.
>
> Hm. It seems to be working fine for me when I put it on --module-path without modifications but I’d be curious as to what are your changes.

Yes, it works fine then. It doesn't if you load it on a different
module layer (i.e, not on the boot layer). The change is very simple,
though: https://github.com/sqreen/nashorn/commit/2ae4d7f1f352146e5eae5e00e9947791906841c8#diff-842711a2a0d4c5b3748032280ea00b2eL70

> > As to the jjs executable, that was not a problem, and some tests require it anyway, which is why I worked on it. The only difficult was that when built separately from openjdk, the -J-XXX option is not available, but this can be worked around with the JDK_JAVA_OPTIONS environment variable.
>
> I’ll be curious about that, as I for now haven’t really devoted time to jjs and in fact planned to initially ship the nashorn library without paying much attention to jjs.

I separated jjs in this subproject:
https://github.com/sqreen/nashorn/tree/master/jjs

It's a straightforward jlink task, the only difficulty being the
launcher having to open up some internals classes in the JDK. See
here:
https://github.com/sqreen/nashorn/blob/master/jjs/build.gradle#L21 .
Again, maybe this can be changed to non-jdk implementations of these
libraries.

The nashorn module also needs to export some internal classes to jjs,
but this was already the case before. Exporting those packages
unconditionally is undesirable, if for no other reason  that they
aren't subject to the classpath exception to the GPL.

> Do you already have, or can you maybe sign an Oracle Contributor Agreement[1]? That would allow me (and all other OpenJDK projects) to accept contributions from you.
>

Not yet, but I'll sort that out with Sqreen's management.

-- 
Gustavo Lopes