Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.1pe
    • Fix Version/s: not determined
    • Component/s: logging
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      3,100

      Description

      The java.util.logging.LogManager used within the AppServer appears to have
      global scope, crossing EAR and WAR boundaries.

      The simple test I performed was I used NetBeans to create a base Enterprise App.
      In a session bean, I created a new Logger using:

      Logger log = Logger.getLogger("SessionBean");

      I also did a similar thing in a simple servlet. The simple servlet also called a
      method on the session bean.

      I also created a seperate, standalone test WAR that did a similar thing.

      The servlets and session beans simply dump the contents of the LogManager:

      LogManager lm = LogManager.getLogManager();
      Enumeration<String> e = lm.getLoggerNames();
      while(e.hasMoreElements())

      { System.out.println(e.nextElement()); }

      After running the various experiments, it was soon obvious that the LogManager
      had loggers for both the Session Bean and Servlet delployed in the EAR, as well
      as the Servlet deployed in the standalone WAR.

      It was also obvious that many of the classes from the Appserver had Loggers
      registered with the LogManager.

      There is a concern with common libraries deployed into disparate applications
      within the Appserver, where one application can change the logging level of a
      common class, and have that logging level affect all application within the
      server, even though the actual libraries were deployed in seperate class loaders.

      Also, there is a potential security threat in that an application can be
      installed in to the server, and could add a handler as well as change the
      logging level of all the Loggers in the system. Potentially routing that logging
      information to an offsite server. It is easy to see a potential scenario where
      there may be some debug logging at FINE or FINEST that could contain connection
      information, including passwords. If anyone can attach a Handler to any Logger
      in the system, as well as change the logging level, then an attacker could
      harvest any sensitive information posted in log messages.

      And far be it for me to fixate on mere passwords, but in the health care
      industry, you can easily see someone posting a log message containing sensitive
      patient information.

      As I see there seems to be movement to try and get Glassfish in to a public
      hosting role, this becomes an even more important issue.

        Activity

        Hide
        bertschultheiss added a comment -
            • Issue 3100 has been confirmed by votes. ***
        Show
        bertschultheiss added a comment - Issue 3100 has been confirmed by votes. ***
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Hide
        vindum added a comment -

        I agree. This is indeed a problem. I'm implementing log4j using slf4j, and this problem makes jul-to-slf4j send log messages through appenders from other applications than the ones they originated from. It makes tracking log messages very difficult.

        Show
        vindum added a comment - I agree. This is indeed a problem. I'm implementing log4j using slf4j, and this problem makes jul-to-slf4j send log messages through appenders from other applications than the ones they originated from. It makes tracking log messages very difficult.

          People

          • Assignee:
            dpatil
            Reporter:
            whartung
          • Votes:
            5 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: