Uploaded image for project: 'Apache Storm'
  1. Apache Storm
  2. STORM-4023

Background periodic Kerberos re-login should use same JAAS configuration as initial login

    XMLWordPrintableJSON

Details

    Description

      In the Login class, a background thread is started that periodically performs a re-login to the Kerberos Ticket Granting Server.

      For the initial login, a custom Configuration instance is created and supplied to the LoginContext constructor potentially using a custom JAAS file location.

      However, the background refresh thread does not then subsequently provide the JAAS file location or Configuration to the reLogin method, so it tries to construct a LoginContext with just a context name and subject but no Configuration parameter, which means that the underlying Configuration.getConfiguration() call has to load one from system defaults, which could possibly specify a different file or none at all.

      In our application where this issue was found, we had set the java.security.auth.login.config value to a valid JAAS file location as a Storm client property along with other standard connectivity properties, since the Netty client framework loads it from the topology configuration. It looks like the Netty server framework does the same as well. The initial login succeeded and the following Storm Nimbus interactions were successful, but a while later it lost the ability to communicate with Storm with this error being logged,

      ERROR [Refresh-TGT] org.apache.storm.messaging.netty.Login Could not refresh TGT for principal: <REDACTED>
      javax.security.auth.login.LoginException: No LoginModules configured for StormClient
         at java.base/javax.security.auth.login.LoginContext.init(LoginContext.java:267)
         at java.base/javax.security.auth.login.LoginContext.<init>(LoginContext.java:385)
         at org.apache.storm.messaging.netty.Login.reLogin(Login.java:409)
         at org.apache.storm.messaging.netty.Login$1.run(Login.java:222)
         at java.base/java.lang.Thread.run(Thread.java:829)
      

      It appears that a viable workaround for this issue is to also set the system property,

      -Djava.security.auth.login.config=/some/path/jaas.conf

      for the application, referencing the same JAAS file location as was set in the Storm configuration. After doing so the background refresh thread was able to correctly function in our situation.

      To address this, we can update the reLogin method to use the same JAAS configuration. Furthermore it should use the same callback handler instance that was originally provided also, instead of creating a new default one.

      Attachments

        Activity

          People

            Unassigned Unassigned
            noslowerdna Andrew Olson
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 20m
                20m