RE: Moving system properties to gnu.classpath.*

[Jeroen Frijters]

Michael Koch wrote:
> Am Freitag, 8. Oktober 2004 09:42 schrieb Stephen Crawley:
> > address@hidden said:
> > > I would like to make this new class public to do away with the
> > > overhead (and initialization dependencies) of the security check,
> > > but that would require some VM magic to make the class
> > > inaccessible from untrusted code. Michael Koch (strongly) opposes
> > > this. How would you feel about it?
> >
> > Speaking as yet another JVM implementor, I'm against this idea for
> > the reasons given by Michael and others.
> 
> In order to find a solution would the following be a solution 
> for you: 
> 
> public final class VMSecureProperties
> {
> public String getProperty(String propName, String defaultValue)
> {
>   GetPropertyAction getProp = new GetPropertyAction(propName, 
> defaultValue);
>     return (String)AccessController.doPrivileged(getProp);
> }
> }
> 
> This reduces out code duplication and should it make possible to do 
> whatever you want inside your VM.

This is basically what I proposed, but it is a security hole. Any code
can call VMSecureProperties.getProperty, because it's public (and it
needs to be public because it is accessed from all over Classpath).

However, I just discovered that we don't need a VM hack to shield off
the gnu.classpath package (or whatever package we pick), it is supported
functionality by the VM. Whenenever code tries to access a package and a
security manager is installed, SecurityManager.checkPackageAccess() is
called, so all we need to do is all the gnu.classpath package to the
package.access system property.

Regards,
Jeroen