> Thats no more secure or safe than current version. You could simply do
> something like
>
> Thread.currentThread.
> setContextClassLoader( mySecureObject.getClass().getClassLoader() );
If you are not using a security manager, the untrusted code can do much
worse - it can load native library ( for example ), access anything in
memory ( via native or similar methods ). Or it can read/write any files
it wants, so accessing the logger of another application is the least
problem.
You can't protect anything - maybe just get a false ( and dangerous )
illusion of security.
In a sandbox, however, you can't call setContextClassLoader() unless you
have the right permission, so untrusted code can't do any harm. And
that's the goal - to keep untrusted application isolated and not give
them any additional "tools".
> Category c = Category.getInstance( "auth" );
> c.setAppenders( myEvilSubversiveAppenders );
>
> This will work when security is turned off or on any complex
> webapps/applications.
Again, with security off - it doesn't matter anyway. With security on,
setting appenders is very tricky - you don't want it to set a
FileAppender ("/etc/passwd" ). And you want some appenders to be
priviledged so they can write to syslog or some log dir.
> In Avalon we came across much of these same problems a while back. The only
> real solution was to change the paradigm. Instead of static access you get
> access via an interface. SOmething like
I know, but that has it's limitations as well - it works great if you
have dumb components and a smart framework.
So far all logging I've seen are based on the current paradigm, of user
code controlling a hierarchy of loggers, and that seems to be the
problem we have to resolve.
Costin
