Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security permissions are not being checked in ContentionHandler first when using a TwitterServer #281

Closed
alilewin opened this issue Aug 5, 2020 · 1 comment

Comments

@alilewin
Copy link

alilewin commented Aug 5, 2020

When running some Finatra feature tests in scala for a TwitterServer, permissions in the JVM SecurityManager policy are not first being checked before trying to invoke that code. Is this expected, and if so is this something we want to change?

Expected behavior

When running some Finatra feature tests, I ran into this JVM security error:

                     Waiting for warmup phases to complete...
                     Waiting for warmup phases to complete...

                     Embedded server MyServer failed to startup: access denied ("java.lang.management.ManagementPermission" "control")
                     java.security.AccessControlException: access denied ("java.lang.management.ManagementPermission" "control")
                     	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
                     	at java.security.AccessController.checkPermission(AccessController.java:884)
                     	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
                     	at sun.management.Util.checkAccess(Util.java:77)
                     	at sun.management.Util.checkControlAccess(Util.java:85)
                     	at sun.management.ThreadImpl.setThreadContentionMonitoringEnabled(ThreadImpl.java:189)
                     	at com.twitter.jvm.ContentionSnapshot.<init>(ContentionSnapshot.scala:14)
                     	at com.twitter.server.handler.ContentionHandler.<init>(ContentionHandler.scala:10)
                     	at com.twitter.server.Admin$.adminRoutes(Admin.scala:67)
                     	at com.twitter.server.AdminHttpServer$$anonfun$1.apply$mcV$sp(AdminHttpServer.scala:296)
                     	at com.twitter.app.App$$anonfun$nonExitingMain$3.apply(App.scala:361)
                     	at com.twitter.app.App$$anonfun$nonExitingMain$3.apply(App.scala:361)
                     	at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
                     	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
                     	at com.twitter.app.App$class.nonExitingMain(App.scala:361)
                     	at /path/to/my/server.MyServer.nonExitingMain(FakeServer.scala:17)
                     	at com.twitter.inject.server.EmbeddedTwitterServer$$anonfun$runNonExitingMain$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(EmbeddedTwitterServer.scala:626)
                     	at com.twitter.inject.server.EmbeddedTwitterServer.withLocals(EmbeddedTwitterServer.scala:597)
                     	at com.twitter.inject.server.EmbeddedTwitterServer$$anonfun$runNonExitingMain$1.apply$mcV$sp(EmbeddedTwitterServer.scala:624)
                     	at com.twitter.inject.server.EmbeddedTwitterServer$$anonfun$runNonExitingMain$1.apply(EmbeddedTwitterServer.scala:624)
                     	at com.twitter.inject.server.EmbeddedTwitterServer$$anonfun$runNonExitingMain$1.apply(EmbeddedTwitterServer.scala:624)
                     	at com.twitter.util.Try$.apply(Try.scala:26)
                     	at com.twitter.util.ExecutorServiceFuturePool$$anon$4.run(FuturePool.scala:140)
                     	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
                     	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                     	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
                     	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
                     	at java.lang.Thread.run(Thread.java:748)

While I understand a fix would be to just update my SecurityManager policy, I'm filing this issue because I was told we should likely be checking permissions in the ContentionSnapshot code before trying to invoke the ManagementFactory (see last two paragraphs here for more details.

Actual behavior

As described above, it looks like we are not actually doing a permission check before trying to execute the code that triggers this.

Steps to reproduce the behavior

To get this error I simply ran my finatra feature tests with pants.

@cacoco
Copy link
Contributor

cacoco commented Aug 13, 2020

@alilewin addressed this here: twitter/twitter-server@ce783a3

Let us know if that doesn't work for you, it should be in our release next month.

@cacoco cacoco closed this as completed Aug 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants