classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SecurityManager troubles


From: Gary Benson
Subject: Re: SecurityManager troubles
Date: Wed, 11 Jan 2006 09:25:11 +0000

Guilhem Lavaux wrote:
> I have stumbled across a bug probably shared by all VMs using GNU
> Classpath. In Apache Ant a SecurityManager is installed to be able
> to execute java application without forking the VM. Thanks to the SM
> exiting a VM is forbidden and so ant is protected from the
> applications using System.exit(). However it causes us some troubles
> for the cases where we have not pre-loaded some core classes such as
> java.security.Permission/java.security.Security (and probably some
> other). I have attached with this email a testcase which summarises
> quite well the situation.

I found the same problem in Mauve.  This is the thread:
http://lists.gnu.org/archive/html/classpath/2005-12/msg00034.html

My workaround was basically the same as yours:
http://sources.redhat.com/ml/mauve-patches/2006/msg00004.html

> 3) One solution of the problem is to load some core classes. But it
> will appear quite soon that some other classes may also be loaded
> for really wicked applications. It is a limitative solution and I
> would not support it.

Yes.  Exactly which classes need loading depends on exactly what your
custom checkPermission is doing.  We can, of course, make sure we have
the classes we need for the default checkPermission, but that doesn't
seem complete somehow.

> 4) Another solution is to make a special case for selected core
> packages. In that case the class loader will bypass security
> verifications. This is a variant of 3 but less limitative and it
> does not force us to preload classes.

I have a suspicion that the proprietary JVMs must do something like
this...

Cheers,
Gary




reply via email to

[Prev in Thread] Current Thread [Next in Thread]