Re: java.util.ResourceBundle bug?

[Brian Jones <cbj at gnu dot org>]

Mark Wielaard <mark@klomp.org> writes:

> Hi,
> 
> On Sun, Nov 04, 2001 at 02:30:50PM +1300, Bryce McKinlay wrote:
> > 
> > OK, I guess we'll go with this approach then. Is the 
> > AccessController.doPrivileged() actually required, given that 
> > ResourceBundle (and its "private" security manager) will always be 
> > loaded by the bootstrap classloader?
> 
> Permissions depend on the complete Class call chain. If any class in the
> call chain does not have the required permission then the security check
> will fail.
> 
> If a Class is loaded through a reference by another Class then the security
> context of its static initialization blocks is dependend on the complete
> class call chain that made the Class get loaded for the first time.
> (Yes, this does mean that depending on the actual way classes are loaded,
> which might depend on multi-threaded behaviour, class initialization might
> or might not give a SecurityException.)
> 
> But if you can prove that a class is loaded/initialized very early in the
> startup process (without any user class code yet being executed) and it is
> not possible for the Class to get garbage collected (which is often not
> supported for VM bootstrap classes) then the doPrivileged() might not be
> necessary. And even then I would not depend on this behaviour.
> 
> Note that we currently have no actual Permission checking. But most of the
> infrastructure is in place.

I've loosely followed this discussion and I wanted to throw in the
fact that we (Classpath) have a native method (JNI) in
java.util.ResourceBundle currently called getClassContext which is
there just to get around the fact that VMSecurityManager is needed and
resides in java.lang.  I thought that compilers typically barf at
attempting to access package private classes outside of the package,
but I admit to not knowing much about doPrivileged().

Brian
-- 
Brian Jones <cbj@gnu.org>