Skip to main content

ClassLoader causes a SecurityException

7 replies [Last post]
cbonniot
Offline
Joined: 2009-11-16
Points: 0

Hi everybody,

I would like to create a ClassLoader in my Xlet in order to load dynamically some classes.
But, in the constructor of my class which extends ClassLoader, when I call super(), I get a java.lang.SecurityException.

I have the same exception when I try to create a ClassLoader like this :

ClassLoader classLoader = ClassLoader.getSystemClassLoader();

So my question is : is it possible to load classes dynamically ? And if it is, how ?

Thank you.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cbonniot
Offline
Joined: 2009-11-16
Points: 0

Thank you for you great answer ! I will look those classes.

Thank you very much !

cbonniot
Offline
Joined: 2009-11-16
Points: 0

Hi, I looked at what you've told me but both ClassLoader are asking for a URL object.

My problem is that I want to load a class from a file which is on the Blu-Ray disc.

billf
Offline
Joined: 2004-02-13
Points: 0

> Hi, I looked at what you've told me but both
> ClassLoader are asking for a URL object.
>
> My problem is that I want to load a class from a file
> which is on the Blu-Ray disc.

Use a file: URL.

cbonniot
Offline
Joined: 2009-11-16
Points: 0

Yes thank you, but I get the same SecurityException either with URLClassLoader or DVBClassLoader.

I'll keep searching and tell you if I find out a solution.

Thank you for your help.

billf
Offline
Joined: 2004-02-13
Points: 0

Make sure you're calling URLClassLoader.newInstance(), and not the constructor directly. See the specification of the failure mode of both.

cbonniot
Offline
Joined: 2009-11-16
Points: 0

I did call the constructor directly :) but I can't test it right now. I'll keep you updated, thank you for your help !

billf
Offline
Joined: 2004-02-13
Points: 0

It is possible to create a classloader, but there are some important caveats. I'd be _very_ interested in learning how this works out in practice, if you go forward with it.

First, to understand why you got the security exception. This behavior comes out of MHP; part 3-2 is probably silent on it, except for including the relevant MHP clauses (via GEM). So, this is pretty non-obvious, but it is normatively required behavior. The relevant PBP spec statement is the protected constructor ClassLoader(), which says that it throws the SecurityException you're seeing if SecurityManager.checkCreateClassLoader doesn't allow that creation. The permissions section of MHP requires that this permission not be granted (I don't remember precisely how the language ties together on this one -- it's been years since I looked at that part in detail -- but that's the end result).

There are two classloaders you can create: PBP's java.net.URLClassLoader, and DVB's DVBClassLoader. So far, so good, but what permissions do the loaded classes have?

There's some text on URLClassLoader in part 3-2 11.3.1.6. Basically, players earlier than some version, there are no normative guarantees around the permissions granted to classes loaded with URLClassLoader, so the code is treated as untrusted. That's not totally useless; for example, untrusted code can call Class.forName(), and it can call into trusted code that uses e.g. AccessController.doPrivileged(), but dealing with less-trusted code within a trusted xlet where the precise set of permissions granted likely varies by player is something that would require care, and would demand a lot of testing. Even with these limitations, dynamically loading classes is an interesting and powerful technique.

Another avenue to try might be DVBClassLoader. I haven't looked into DVBClassLoader in too much detail, but after a quick search through MHP 1.0.x, I wasn't able to find any stronger normative guarantees around permission grants to loaded classes. Even if there are, I'm not too confident in the level of conformance testing of this API, so I'd tread lightly here.

I think what I'd recommend would be to stick to URLClassLoader. If you can't live with the version constraints from 3-2 § 11.3.1.6, then assume the loaded classes are untrusted, and design the (trusted) library your downloaded code calls accordingly. This is a limitation on the technique, but with sufficient care it's still valuable.