Mark Wielaard <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
