classpath
[Top][All Lists]
Advanced

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

Re: gnu.java.nio.FileChannelImpl


From: Michael Koch
Subject: Re: gnu.java.nio.FileChannelImpl
Date: Fri, 26 Nov 2004 10:44:47 +0100
User-agent: KMail/1.6.2

Am Freitag, 26. November 2004 10:38 schrieb Jeroen Frijters:
> Michael Koch wrote:
> > Did I said I don't like it ?
>
> That's the impression I got when we first discussed this.
>
> > I read some interesting paper from Marc Schoenefeld latetly about
> > how he exploited bugs in SUNs JDK. He has written some tool that
> > uses reflection to test public constructors and methods in sun.*
> > packages.
>
> That doesn't make sense. Untrusted code is not allowed access to
> the sun.* packages (unless you're running on Opera, which
> apparently had a bug), so there is no point.
>
> > We should really make this impossible. Limiting access to some
> > packages in gnu.* namespace (not all) is a good idea. E.g.
> > gnu.java.nio.* should be restricted, gnu.regexp.* not.
>
> Right. We can disallow gnu.* and then selectively allow some
> packages.

What do you do if someone writes a package gnu.foobar and wants to 
access it ? There are some gnu.* packages out there. Do you want to 
maintain the list of packages to allow ? The list of packages we need 
to limit access too is much leaner and well known to us as the 
packages are maintained under our control.

> > This restriction should allow access from java.io, java.nio,
>
> java.lang,
>
> > java.net, etc. but not from non-standard packages like
> > java.foobar. And we have to somehow make sure malicious code can
> > not introduce classes into the standard packages.
>
> That isn't how it works. It's class loader based, all code loaded
> by the bootstrap class loader will have access to the gnu.*
> packages.

Sorry, you are right.


Michael
-- 
Homepage: http://www.worldforge.org/




reply via email to

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