On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi <szege...@gmail.com> wrote: > > On 2020. Oct 12., at 18:41, Gustavo Lopes <gust...@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
