RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java

[co...@covalent.net]

On Thu, 14 Feb 2002, Steve Downey wrote:

> If LogFactory.getLog(getClass()) isn't safe, then security is hopeless. The
> only way it can be safe is if the container arranges for it to be safe. Not
> exposing the container's logging to the webapps is necessary, although not
> sufficient. Using separate classloaders for each webapp is also probably
> required.

What I mean is: if Digester.getLog( getClass() ) calls log4j's 
Category.getInstance( "org.apache....Digester" ), and log4j is installed 
in the common class loader, then all webapps using Digester will have 
their log go to the same place. Think about a hosting service ( ASP ),
you don't want customer's logs mixed.

The LogFactory must be able to support independent hierarchies. It is 
mostly the job of the logger implementation - but the API and the 
wrappers it provides must also support this. For example LogFactoryImpl
is caching instances - so if installed in the common loader it'll
fail to separate apps, regardless of the underlying logger.

Please don't assume the logger will only be loaded in a leaf 
class loader ( i.e. by the webapp, and not in commons ). I would
point again to JAXP - at the beggining you would just put it 
in the webapp and work. But then it started to be used in the container,
and took a rewrite of the container class loader to make it 
possible to use different parsers in different apps. And now
JAXP is part of JDK1.4, in rt.jar.

I don't think commons-logging will end up in JDK1.5, but it's
likley it'll be used in tomcat and in components that have to
be in the common loader. And hopefully tomcat will 'plug' into
the logger - at least to flush the buffers when shutting down,
and more importantely in sandbox mode, to provide the doPriviledged
blocks that will be required.

If you are in a sandbox - no file logger will work. The only 
way to log in a file ( or socket, etc ) is to have  the 
commons-logger.jar in a special location with granted privs,
and use doPriviledged() to allow webapps to log. 

I can't imagine a good way to do that without having commons-logger
in a common class loader.


> In any case, the underlying logging package *has* to provide the same
> facility. Otherwise, using the native logging api would subvert security.

The API must be designed with security and container-use in mind - it's 
extremely hard to add it back later. Of course the underlying logging
package has to be secure - but if the logging API is caching the 
Log keyed on name it'll just brake whatever the logging impl. does.

Now we use the thread class loader as a namespace - and we're 
ok. A guard or similar mechanism is still needed if you want 
to share logs between apps - but that's probably not a big priority.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>