Spring Security
  1. Spring Security
  2. SEC-1386

Spring Security-enabled web applications take a long time to start on Tomcat on VMware guest

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu 9.10
      Linux vm_172_23_10_8 2.6.31-17-server

      java version "1.6.0_15"
      Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
      Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)

      tcServer 6.0

      Description

      I'm running tcServer in a cluster on top of VMware ESXi server. When I try and start tcServer (or plain Tomcat 6, for that matter) with a webapp that is Spring Security 3 enabled, it takes 5 minutes or more for the server to fully start. When I symlink /dev/random to /dev/urandom, it starts up normally.

      I have /dev/urandom set as the source for my entropy in the system java.security settings. I've also passed -Djava.security.egd=file:/dev/urandom to tcServer per the thread: http://bugs.sun.com/view_bug.do;jsessionid=81ead47d172a98bb75bbdf7fc78?bug_id=4705093

      I don't really know what else to try. Every time I reboot, any changes I make to /dev/random revert to the stock, blocking random generator. When I comment out Spring Security, everything start fine.

        Activity

        Hide
        Luke Taylor added a comment -

        I don't really understand why do you think this is a major bug in Spring Security? There doesn't seem to be any evidence for that here.

        Show
        Luke Taylor added a comment - I don't really understand why do you think this is a major bug in Spring Security? There doesn't seem to be any evidence for that here.
        Hide
        Jon Brisbin added a comment -

        Since I'm running Spring Security inside a VM guest, it's either let the application servers take up to five minutes to start (times the number of nodes I have...this tends to be burdensome and affects my uptime) by letting Spring Security use /dev/random, or do what I've done for the workaround, which is to create an /etc/init.d script that symlinks /dev/random to /dev/urandom. That's a pretty rough workaround, but the only one that works reliably.

        Spring Security uses SecureRandom in places (which I think uses the blocking /dev/random for entropy). As far as I have been able to test, this is what's causing a 3-5 minute delay in startup on Spring Security-enabled webapps on Linux VM guests. /dev/random's entropy pool does not get filled very quickly on a VM guest. If Spring Security was coded to use /dev/urandom exclusively, applications that use it would not suffer this startup delay.

        If it's not desirable to use /dev/urandom exclusively, then it should at least be configurable so that applications that run on application servers inside VM guests don't have to block on their startup. Or provide some other method to get entropy than by using the blocking /dev/random.

        I don't know if this is specific to Xen/VMware or if VirtualBox also suffers from this.

        Show
        Jon Brisbin added a comment - Since I'm running Spring Security inside a VM guest, it's either let the application servers take up to five minutes to start (times the number of nodes I have...this tends to be burdensome and affects my uptime) by letting Spring Security use /dev/random, or do what I've done for the workaround, which is to create an /etc/init.d script that symlinks /dev/random to /dev/urandom. That's a pretty rough workaround, but the only one that works reliably. Spring Security uses SecureRandom in places (which I think uses the blocking /dev/random for entropy). As far as I have been able to test, this is what's causing a 3-5 minute delay in startup on Spring Security-enabled webapps on Linux VM guests. /dev/random's entropy pool does not get filled very quickly on a VM guest. If Spring Security was coded to use /dev/urandom exclusively, applications that use it would not suffer this startup delay. If it's not desirable to use /dev/urandom exclusively, then it should at least be configurable so that applications that run on application servers inside VM guests don't have to block on their startup. Or provide some other method to get entropy than by using the blocking /dev/random. I don't know if this is specific to Xen/VMware or if VirtualBox also suffers from this.
        Hide
        Luke Taylor added a comment -

        How SecureRandom is configured can vary between different platforms and VMs. Spring Security just uses the class in a standard way, so presumably you would see the same behaviour in any library or application which uses it. The source from which it is seeded should be selected in your java.security file. It's not something that Spring Security should be deciding.

        Show
        Luke Taylor added a comment - How SecureRandom is configured can vary between different platforms and VMs. Spring Security just uses the class in a standard way, so presumably you would see the same behaviour in any library or application which uses it. The source from which it is seeded should be selected in your java.security file. It's not something that Spring Security should be deciding.
        Hide
        Jon Brisbin added a comment -

        I'm already using /dev/urandom in my java.security file:

        securerandom.source=file:/dev/urandom

        But somehow Spring Security is using something that generates randomness (maybe it's plain java.util.Random?) that is using /dev/random instead of /dev/urandom.

        One way or another, I think Spring Security should account for this long startup time. If the stance is to punt this issue, that's all well and good, but that doesn't help me any. People coming along behind us should be aware that this is an issue. It looks likes the code is not so replete with references to random generators that they can't be tweaked in just key spots to accommodate this behavior in cloud environments. I'm sure there's more than one way to use those standard objects to get the same result...and do it in a way that doesn't trigger this behavior. That's all I'm talking about.

        If the Spring team disagrees and thinks those tweaks are a waste of time, then, as I said, so be it. But no where that I could find is this issue addressed.

        Show
        Jon Brisbin added a comment - I'm already using /dev/urandom in my java.security file: securerandom.source= file:/dev/urandom But somehow Spring Security is using something that generates randomness (maybe it's plain java.util.Random?) that is using /dev/random instead of /dev/urandom. One way or another, I think Spring Security should account for this long startup time. If the stance is to punt this issue, that's all well and good, but that doesn't help me any. People coming along behind us should be aware that this is an issue. It looks likes the code is not so replete with references to random generators that they can't be tweaked in just key spots to accommodate this behavior in cloud environments. I'm sure there's more than one way to use those standard objects to get the same result...and do it in a way that doesn't trigger this behavior. That's all I'm talking about. If the Spring team disagrees and thinks those tweaks are a waste of time, then, as I said, so be it. But no where that I could find is this issue addressed.
        Hide
        Luke Taylor added a comment -

        Spring Security is just using SecureRandom.getInstance() in the codebase. That's presumably why you are seeing this behaviour. Have you tried just writing a simple app which does nothing other than this and see if you get the same behaviour? We don't use java.util.Random, and that uses a time-based seed, so shouldn't cause a problem.

        You really need to work out why "/dev/random" is being used, when your configuration indicates that it shouldn't be.

        Show
        Luke Taylor added a comment - Spring Security is just using SecureRandom.getInstance() in the codebase. That's presumably why you are seeing this behaviour. Have you tried just writing a simple app which does nothing other than this and see if you get the same behaviour? We don't use java.util.Random, and that uses a time-based seed, so shouldn't cause a problem. You really need to work out why "/dev/random" is being used, when your configuration indicates that it shouldn't be.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jon Brisbin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: