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();
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
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.