Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-67000

JavaWebStart agents cannot connect due to AccessControlException

    • 2.335,2.332.1

      This week after the jenkins update of 2.317 and to 2.318 , my agent machine (windows 10) start getting terminated again and again after connected

       

      As normally I use jnlp file right click to launch , the jenkins agent windows appears and I can see Connected but within few seconds its got Terminated

       

      I went into the remoting folder to check out the logs and it prompts this error

       

      Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read")

       

      Agent Java version : OpenJDK 1.8.0 301
      Jenkins version : Jenkins 2.318

      I am using Openwebstart for jnlp

       

      Complete log message (agent machine)

      Okt 26, 2021 9:53:03 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
      INFORMATION: Remoting server accepts the following protocols: [JNLP4-connect, Ping]
      Okt 26, 2021 9:53:03 AM org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader run
      INFORMATION: Waiting for ProtocolStack to start.
      Okt 26, 2021 9:53:08 AM hudson.remoting.UserRequest perform
      WARNUNG: LinkageError while performing UserRequest:hudson.slaves.SlaveComputer$SlaveInitializer@6cfcc55d
      java.lang.ExceptionInInitializerError
      at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1042)
      at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1033)
      at hudson.remoting.UserRequest.perform(UserRequest.java:211)
      at hudson.remoting.UserRequest.perform(UserRequest.java:54)
      at hudson.remoting.Request$2.run(Request.java:376)
      at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:122)
      at java.lang.Thread.run(Unknown Source)
      Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read")
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
      at java.lang.System.getProperty(Unknown Source)
      at java.lang.Integer.getInteger(Unknown Source)
      at java.lang.Integer.getInteger(Unknown Source)
      at hudson.util.RingBufferLogHandler.<clinit>(RingBufferLogHandler.java:39)
      ... 11 more

       

          [JENKINS-67000] JavaWebStart agents cannot connect due to AccessControlException

          Christoph added a comment - - edited

          We have the same issue in our environment. It probably started with the update from 2.289.1 to 2.319.2.

           

          A workaround that is working on our system is to replace the remoting...jar in the directory war\WEB-INF\lib (and then restart jenkins)

          Shipped with 2.139.2 we had the file remoting-4.11.2.jar.

          I have tried the old versions. The last one that is working is remoting-4.10.1.jar.

          So I guess a change in remoting 4.11 is causing this.

           

          When comparing 4.10.1 and 4.11. I found this pull request: https://github.com/jenkinsci/remoting/pull/481/files

          The file is: src/main/java/hudson/remoting/jnlp/Main.java 

          They removed a try-catch-block that basically disabled security exceptions.

          From what I can see from the pull request they just removed it because all the links that were mentioned are dead now.

          Maybe this try-catch-block just skipped the java.security.AccessControlException and now it doesn't anymore.

          Christoph added a comment - - edited We have the same issue in our environment. It probably started with the update from 2.289.1 to 2.319.2.   A workaround that is working on our system is to replace the remoting...jar in the directory war\WEB-INF\lib (and then restart jenkins) Shipped with 2.139.2 we had the file remoting-4.11.2.jar. I have tried the old versions. The last one that is working is remoting-4.10.1.jar. So I guess a change in remoting 4.11 is causing this.   When comparing 4.10.1 and 4.11. I found this pull request: https://github.com/jenkinsci/remoting/pull/481/files The file is: src/main/java/hudson/remoting/jnlp/Main.java   They removed a try-catch-block that basically disabled security exceptions. From what I can see from the pull request they just removed it because all the links that were mentioned are dead now. Maybe this try-catch-block just skipped the java.security.AccessControlException and now it doesn't anymore.

          Mark Waite added a comment -

          A workaround that is working on our system is to replace the remoting.jar in the directory war\WEB-INF\lib (and then restart jenkins)

          That's a scary workaround, since that removes the security fixes that were applied in remoting 4.11.2. It seems like a challenging workaround to maintain, since I would expect that file to be overwritten each time a new Jenkins version is installed.

          Mark Waite added a comment - A workaround that is working on our system is to replace the remoting.jar in the directory war\WEB-INF\lib (and then restart jenkins) That's a scary workaround, since that removes the security fixes that were applied in remoting 4.11.2. It seems like a challenging workaround to maintain, since I would expect that file to be overwritten each time a new Jenkins version is installed.

          Christoph added a comment -

          markewaite true it's not a nice workaround. I just wanted to help pointing to the root cause of this.

          Hoping the change that happened there gets fixed in the next version. (I have added some more details to the original post)

          Christoph added a comment - markewaite true it's not a nice workaround. I just wanted to help pointing to the root cause of this. Hoping the change that happened there gets fixed in the next version. (I have added some more details to the original post)

          Todd Vogl added a comment -

          We ended up going a different route:

           

          Downloaded the agent.jar into c:\Jenkins

          Put the java -jar agent.jar -jnlpUrl …….   Into a agent_start.cmd file located in the same directory

           

          Then created a "Jenkins Agent" task in Task Scheduler to RUN at startup

          In the action tab program/script is set to cmd

          add arguments:    /c c:\Jenkins\agent_start.cmd >C:\Jenkins\remoting\logs\remoting.log 2>&1 

          Start in: C:\Jenkins

           

          Then added some powershell scripts to start and stop the node.  You can’t start it from the Jenkins controller using this method shown above…. So that is a drawback… but You can from the server.  So I created 2 simple powershell scripts I put into Jenkins jobs.  This allows you to start and stop the node from Jenkins without granting access to the server directly or the need to log into the server just to start the node.

          Stop-ScheduledTask -TaskName "Jenkins Agent"

          Start-ScheduledTask -TaskName "Jenkins Agent"

           

          So far this has been working great

           

           

          Todd Vogl added a comment - We ended up going a different route:   Downloaded the agent.jar into c:\Jenkins Put the java -jar agent.jar -jnlpUrl …….   Into a agent_start.cmd file located in the same directory   Then created a "Jenkins Agent" task in Task Scheduler to RUN at startup In the action tab program/script is set to cmd add arguments:    /c c:\Jenkins\agent_start.cmd >C:\Jenkins\remoting\logs\remoting.log 2>&1  Start in: C:\Jenkins   Then added some powershell scripts to start and stop the node.  You can’t start it from the Jenkins controller using this method shown above…. So that is a drawback… but You can from the server.  So I created 2 simple powershell scripts I put into Jenkins jobs.  This allows you to start and stop the node from Jenkins without granting access to the server directly or the need to log into the server just to start the node. Stop-ScheduledTask -TaskName "Jenkins Agent" Start-ScheduledTask -TaskName "Jenkins Agent"   So far this has been working great    

          Jesse Glick added a comment -

          Reproduced in a trunk build using the Ubuntu package icedtea-netx. This is a genuine accidental regression. Certainly we do not recommend users use JWS to attach agents, but it remains an option offered in the GUI.

          Jesse Glick added a comment - Reproduced in a trunk build using the Ubuntu package icedtea-netx . This is a genuine accidental regression. Certainly we do not recommend users use JWS to attach agents, but it remains an option offered in the GUI.

          Jeff Thompson added a comment -

          a07855, that's a much better approach for a variety of reasons. One recommended enhancement. Your task should download the agent jar when the task starts and then run the agent. This allows it to keep updated with new agent / remoting versions, at least when the task runs.

          Jeff Thompson added a comment - a07855 , that's a much better approach for a variety of reasons. One recommended enhancement. Your task should download the agent jar when the task starts and then run the agent. This allows it to keep updated with new agent / remoting versions, at least when the task runs.

          Jesse Glick added a comment -

          Merged in Remoting; awaiting Remoting release, and integration of that into a weekly.

          Jesse Glick added a comment - Merged in Remoting; awaiting Remoting release, and integration of that into a weekly.

          Mark Waite added a comment -

          Remoting 4.12 release 7 Feb 2022. Pull request 6261 submitted by dependabot to include it in a future release of Jenkins core.

          Mark Waite added a comment - Remoting 4.12 release 7 Feb 2022. Pull request 6261 submitted by dependabot to include it in a future release of Jenkins core.

          Shelly Gez added a comment -

          Any ETA for the release with the fix of this issue?

          Shelly Gez added a comment - Any ETA for the release with the fix of this issue?

          Mark Waite added a comment - - edited

          Pull request 6261 is merged into the master branch that should be released tomorrow as 2.335. It is also included in the proposed backports to be included in the 2.332.1 LTS release March 9, 2022.

          Mark Waite added a comment - - edited Pull request 6261 is merged into the master branch that should be released tomorrow as 2.335. It is also included in the proposed backports to be included in the 2.332.1 LTS release March 9, 2022.

            jglick Jesse Glick
            testengineer Bilawal Ali
            Votes:
            2 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: