Michael Koch wrote:
> Am Freitag, 8. Oktober 2004 09:42 schrieb Stephen Crawley:
> > [EMAIL PROTECTED] 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
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
