[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving system properties to gnu.classpath.*
From: |
Michael Koch |
Subject: |
Re: Moving system properties to gnu.classpath.* |
Date: |
Fri, 8 Oct 2004 12:12:10 +0200 |
User-agent: |
KMail/1.6.2 |
Am Freitag, 8. Oktober 2004 10:15 schrieb 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).
Sorry, this was a fast hack inside my kmail .... ;-)
> 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.
Provide some code and we will see what comes out of the discussion.
I have to say I wasn't aware of this
SecurityManager.checkPackageAccess() method before.
Michael
--
Homepage: http://www.worldforge.org/
- RE: Moving system properties to gnu.classpath.*, (continued)
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/07
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/07
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/08
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/08
- Re: Moving system properties to gnu.classpath.*,
Michael Koch <=
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11