[GLASSFISH-3100] LogManager has global scope Created: 31/May/07  Updated: 19/Sep/12

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: whartung Assignee: dpatil
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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.



 Comments   
Comment by bertschultheiss [ 09/Sep/10 ]
      • Issue 3100 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by vindum [ 19/Sep/12 ]

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.

Generated at Thu Sep 29 02:55:04 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.