Lists: | pljava-dev |
---|
From: | nathanegge at yahoo(dot)com (Nathan Egge) |
---|---|
To: | |
Subject: | [Pljava-dev] SecurityManager and Equinox OSGi |
Date: | 2011-10-11 16:00:23 |
Message-ID: | 1318348823.53847.YahooMailNeo@web35704.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pljava-dev |
Hi Johann,
Thank you for all your hard work. ?I have been using pl/Java for quite sometime and am happy to see it actively maintained and developed once again.
Recently I rebuilt my project using OSGi so I could have multiple versions of the same jar in the same application. ?This worked well when running as a stand alone project, but when embedded in pl/Java I kept getting a BundleException due to missing permissions:
org.osgi.framework.BundleException: The bundle "com.myproject_1.0.0 [1]" could not be resolved. Reason: Missing Permission: (org.osgi.framework.PackagePermission javax.sql exportonly), Missing Constraint: Import-Package: javax.sql; version="0.0.0"
After sometime with the remote debugger, I traced the reason back to the fact that when there is a SecurityManager present, Equinox OSGi uses a java.security.ProtectionDomain to check for export permissions and doesn't expose any of the default packages from rt.jar. ?I am running this as untrusted code (LANGUAGE javaU) so I simply modified Backend.java to allow me to clear the SecurityManager, i.e., System.setSecurityManager(null), from inside the static method call.
I was wondering,?do you have any plans to either (1) remove the SecurityManager from untrusted code execution or (2) fix the java.security.* issues so that OSGi permission checking works? ?I am currently able to work around this just fine via a patch, but I am not sure how many other libraries are impacted by the presence of a SecurityManager.
I am happy to provide a working example if it would help.
Sincerely,
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20111011/d2b1eb9f/attachment.html>