Skip to main content

Class loading and permissions

6 replies [Last post]
khendry
Offline
Joined: 2004-08-13
Points: 0

As I read it in the specs applications are prohibited from creating their own class loader instance to load classes. I've based this on the MHP spec indicating that neither signed nor unsigned applications will be given the java permission RuntimePermission granted.

However currently it seems that creating a custom class loader is permitted on the RI. We've also testing this on other platforms and had some success. However others do not seem to allow it.

What is the expected behavior here and what should the RI be doing in this case? Is there potentially a case of miss-configuration or something to that affect that is causing the RI to allow this functionality?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03
Points: 0

I ran the test code that you provided and it threw a SecurityException as expected. OCAP Permission checks are enabled by default, so I can't think of any reason right now why this would be succeeding for them. Perhaps you can copy their signalling file here so I can see that?

khendry
Offline
Joined: 2004-08-13
Points: 0

app.0.application_identifier=0x0000111271A0
app.0.application_control_code=AUTOSTART
app.0.visibility=VISIBLE
app.0.priority=220
app.0.base_directory=/syscwd/qa/xlet
app.0.application_name=ClassXlet
app.0.initial_class_name=com.tvworks.client.sl.classxlet.ClassXlet

greg80303
Offline
Joined: 2008-07-03
Points: 0

OK -- I see what is going on here.

The stack has a back door for Host Device Manufacturer Applications (HDMA) that grants them all permissions when their AppID is greater than 0x7000. This is a back door that I believe needs to be closed. I have created an internal project issue to track this.

In the meantime, tell your colleagues to lower the AppID to something between 0x6000 and 0x6fff and they will begin to see the exception. The other option (and perhaps more recommended) is to not treat your apps as HDMAs because I believe that it is not your intention. The spec has some very different rules about how HDMAs should be handled. Instead use "xait.properties" and modify your mpeenv.ini file to make sure that you are using the file-based signalling and NOT ignoring XAITs:

OCAP.xait.ignore=false
OCAP.mgrmgr.Signalling=org.cablelabs.impl.manager.signalling.TestSignallingMgr

Refer to this Wiki page for more information on file-based signalling:

https://devzone.cablelabs.com/widget/web/ocapri/1/-/wiki/OCAP%20RI%20Pub...

greg80303
Offline
Joined: 2008-07-03
Points: 0

I agree that OCAP does not provide any conditions under which an application can be granted RuntimePermissions("createClassLoader").

Can you post some example code? I wrote a simple test Xlet that created its own ClassLoaders that derived from java.lang.ClassLoader and java.security.SecureClassLoader. Both of these threw SecurityExceptions upon construction as I would expect.

MHP provides the org.dvb.lang.DVBClassLoader class to allow very limited access to custom class loading. The constructors of DVBClassLoader will throw SecurityExceptions just like expected. However DVBClassLoader.getInstance() will not throw SecurityException and can be used safely by OCAP apps to load classes from custom URLs. All loaded classes will go through all appropriate authentication and security procedures as indicated by the calling app.

G

khendry
Offline
Joined: 2004-08-13
Points: 0

I'll send you a sample xlet. I'd attach it here, but I don't see that option.

khendry
Offline
Joined: 2004-08-13
Points: 0

I also just checked that they guys that tried this were using the default mpeenv.ini settings.