Issue when using Vert.x with Java Security Manager

[Teja Pitla]

Hello all,

 

I am experiencing an unusual issue when using Vert.x with the default Java security manager. I am running my code under a very simple java security policy that unconditionally grants full permissions to all code. My expectation is that under these conditions, my application should behave identical to being run without any security manager enabled.

I have created a simple example to demonstrate my issue. I have a JavaScript verticle that gets deployed by my Java app. The JS verticle simply uses the java.lang.Thread class to get the name of the current thread and publishes it to the event bus which the Java app reads and prints to the console. The JS verticle also has a handler that again repeats the action of reading the thread name and publishing to the event bus. 

I am running this Java code:

import io.vertx.core.Vertx;
import io.vertx.core.eventbus.EventBus;

public class Permissions {

 public static void main(String[] args) throws Exception {
 Vertx vertx = Vertx.vertx();
 EventBus eb = vertx.eventBus();

 eb.consumer("java", res -> {
 System.out.println(res.body());
 });

 vertx.deployVerticle("Permissions.js", result -> {
 eb.publish("js", "FooBarThread");
 });
 }
}

with this security policy:

grant {
 permission java.security.AllPermission;
};

and with these JVM args:

-Djava.security.manager -Djava.security.policy==src/main/resources/security.policy

The JavaScript verticle is as follows:

var eb = vertx.eventBus();
//eb.publish("java", java.lang.Thread.currentThread().getName());

eb.consumer("js", function (message) {
 eb.publish("java", java.lang.Thread.currentThread().getName());
});

For reasons that I am not understanding, this code throws an AccessControlException if the first call to the publish method is commented out or removed. 

SEVERE: Unhandled exception



java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setContextClassLoader")

 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457)

 at java.security.AccessController.checkPermission(AccessController.java:884)

 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)

 at java.lang.Thread.setContextClassLoader(Thread.java:1467)

 at io.vertx.core.impl.ContextImpl.setTCCL(ContextImpl.java:344)

 at io.vertx.core.impl.ContextImpl.setContext(ContextImpl.java:97)

 at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:312)

 at io.vertx.core.impl.ContextImpl$$Lambda$11/1853495960.run(Unknown Source)

 at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)

 at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:418)

 at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:440)

 at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:873)

 at java.lang.Thread.run(Thread.java:745)

As long as the initial publish call is made (or you disable the security manager), everything works as expected. 

I have also attached a gradle/intellij project for this project, you can use the run task in gradle to execute it. Try commenting and uncommenting the first "eb.publish" method call in the Javascript code to see the differences in behavior. 

 

 

This behavior seems unexpected to me and I am not sure if I am missing something here. Any guidance on this would be greatly appreciated. 

Thanks, 

Teja

[Julien Viet]

Hi,

I don’t see the attached code you mentioned.

Julien

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4cd9301b-04c3-4333-afff-1509e484b992%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Teja Pitla]

Sorry, I had tried to upload the file here but it wouldn't let me post it. I have uploaded it to Dropbox. 

https://www.dropbox.com/s/1uxkupxhszgk2y8/vertx_security_manager_test.zip?dl=0

Thanks, 

Teja

[Jochen Bedersdorfer]

I'd appreciate if someone could look at that.

It currently prevents us from taking Vert.x into production.

If there's anything else we can provide, please let us know.

Deploying a verticle like this:

var eb = vertx.eventBus();
//eb.publish("java", java.lang.Thread.currentThread().getName());

eb.consumer("js", function (message) {
 eb.publish("java", java.lang.Thread.currentThread().getName());
});

triggers the exception, however, uncomment line 2 and the error goes away!

it looks like some lazily evaluated setup for `publish` changes the security context.

Any pointers would be great!

Thanks a lot,

  Jochen

--

Jochen Bedersdorfer

Application Architect - Intel

[Jochen Mader]

Have you tried adding the following permission:

permission java.lang.RuntimePermission "setContextClassLoader";

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/fa855204-8a42-492e-88a3-e9abc5c79f3f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Julien Viet]

Hi,

it seems related to Nashorn and it is quite hard (not impossible :-) ) to investigate what is really going on.

I’ve tried the URLReader thing explained here https://wiki.openjdk.java.net/display/Nashorn/Nashorn+script+security+permissions but it does not solve the issue.

One way to solve it I think is to use a privileged action to set the thread context class loader in Vert.x , so the Nashorn execution does not affect the execution of Vert.x which has proper permission grants. I’ve tried it and it solves the issue, so it could be in 3.4.

There is a work around with your test : set the system property -Dvertx.disableTCCL=true , that will skip the TCCL set (which may have consequence), and other similar security checks may happen.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[Julien Viet]

here is a better work-around :

after Vert.x is created in your main execute:

for (int i = 0;i < VertxOptions.DEFAULT_EVENT_LOOP_POOL_SIZE;i++) {
    vertx.getOrCreateContext().runOnContext(v -> {});
}

The security issue we observe is due to the fact that the thread is created in the eb.publish() , the publish method schedules the message on the EventBus consumer registered in the Permission#main method.

This thread is lazily created within Nashorn and inherits the protection domains at this creation moment. When the security checks occurs, the security check and inherits these and the security check fails (because it contains a staticPermissions domains created by Nashorn).

Scheduling a task on all contexts will force the creation of threads ahead of time and avoid the issue (ideally DEFAULT_EVENT_LOOP_SIZE / 2 is enough).

At the end it looks more like a Nashorn / Security Manager issue as you grant all permissions and there is still a failure because of Nashorn. Nashorn and security clearly lacks of documentation about the configuration.

Julien

[Jochen Bedersdorfer]

Thank you so much, Julien.

We'll try the work-around!

@Jochen (the code had AllPermissions which is why this bug was so puzzling)

[Teja Pitla]

Thanks a lot for looking into this for us Julien. 

-Teja

On Wednesday, February 8, 2017 at 3:31:34 PM UTC-8, Julien Viet wrote: