1 2 Previous Next 26 Replies Latest reply on Oct 20, 2005 11:30 AM by adrian.brock

    Java permissions and JBossXB

    adrian.brock Oct 19, 2005 11:45 AM

      I've been working on running the MC with a SecurityManager enabled.

      To make this work, I've had to wrap the JBossXB calls in a privileged block
      otherwise xerces doesn't find the resolved xml/dtds/xsds.

      
 final Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller();
 PrivilegedExceptionAction action = new PrivilegedExceptionAction()
 {
 public Object run() throws Exception
 {
 return unmarshaller.unmarshal(url.toString(), schemaBinding);
 }
 };
 KernelDeployment deployment;
 try
 {
 deployment = (KernelDeployment) AccessController.doPrivileged(action);
 }
 catch (PrivilegedActionException e)
 {
 throw e.getCause();
 }


      I think this more appropriately belongs in JBossXB?

      • 100098 Views
      • Tags:
        • 1. Re: Java permissions and JBossXB
          starksm64
          starksm64 Oct 19, 2005 4:26 PM (in response to adrian.brock)

          What were the failures, file permission reads? The question is should I have to assign the permission to the ultimate xml/schema file consumer or is assigning the permission to the jbossxb layer sufficient. The issue with this is that I can end up with a java component that cannot read the xml file via the jdk URL/File apis, but can using jbossxb. I'm inclined to say these permissions are not an implementation detail of jbossxb layer and should be required by the caller.

            • Actions
          • 2. Re: Java permissions and JBossXB
            adrian.brock Oct 19, 2005 4:40 PM (in response to adrian.brock)

            If I revert to the previous code I get the following exception with a test (having no permissions) not being able to deploy an xml file (that is not in the same codebase):

            class codebase: output/classes-tests
            resource codebase: output/resources/xml-test

            1705 DEBUG [ArrayXMLTestCase] Using /xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml
1706 DEBUG [ArrayXMLTestCase] url=file:/home/adrian/jboss-head/workspace/kernel/output/resources/xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml
1712 ERROR [ArrayXMLTestCase] Unexpected throwable
org.jboss.xb.binding.JBossXBException: Failed to parse source: access denied (java.io.FilePermission /home/adrian/jboss-head/workspace/kernel/output/resources/xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml read)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:125)
 at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:105)
 at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:85)
 at org.jboss.test.kernel.config.support.XMLUtil.<init>(XMLUtil.java:61)
 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:54)
 at org.jboss.test.kernel.config.test.ArrayXMLTestCase.arrayNotAArray(ArrayXMLTestCase.java:66)
 at org.jboss.test.kernel.config.test.ArrayTestCase.testArrayNotAArray(ArrayTestCase.java:245)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /home/adrian/jboss-head/workspace/kernel/output/resources/xml-test/org/jboss/test/kernel/config/test/testArrayNotAArray.xml read)
 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 at java.security.AccessController.checkPermission(AccessController.java:427)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
 at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
 at java.io.File.isDirectory(File.java:721)
 at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:65)
 at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
 at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
 at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:121)
 ... 27 more


            Maybe the implementation detail of the test (that the xml is in a different codebase)
            is the problem rather than issues relating to the xml parsing?

              • Actions
            • 3. Re: Java permissions and JBossXB
              starksm64
              starksm64 Oct 19, 2005 4:54 PM (in response to adrian.brock)

              No, the output/classes-tests codebase definitely needs the indicated FilePermission. The codebase of the target file URL is only relevant in terms of matching the security policy FilePermission objects. My feeling is that the test should have the permission to read the testArrayNotAArray.xml file in order for it to parse it via jbossxb or else you get into the problem of inconsistent access control based on how the file is read.

                • Actions
              • 4. Re: Java permissions and JBossXB
                adrian.brock Oct 19, 2005 5:00 PM (in response to adrian.brock)

                If I move the xml to the same codebase it fails later when resolving the xsd from xml

                2144 DEBUG [JBossEntityResolver] Failed to obtain URL.InputStream from systemId: file:/home/adrian/jboss-head/workspace/kernel/output/classes-tests/xml-test/org/jboss/
test/kernel/config/test/bean-deployer_1_0.xsd
java.io.FileNotFoundException: /home/adrian/jboss-head/workspace/kernel/output/classes-tests/xml-test/org/jboss/test/kernel/config/test/bean-deployer_1_0.xsd (No such
file or directory)
 at java.io.FileInputStream.open(Native Method)
 at java.io.FileInputStream.<init>(FileInputStream.java:106)
 at java.io.FileInputStream.<init>(FileInputStream.java:66)
 at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
 at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
 at java.net.URL.openStream(URL.java:1007)
 at org.jboss.util.xml.JBossEntityResolver.resolveSystemIDasURL(JBossEntityResolver.java:326)
 at org.jboss.util.xml.JBossEntityResolver.resolveEntity(JBossEntityResolver.java:198)
 at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown Source)
 at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
 at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
 at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
 at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:121)
 at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:105)
 at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:85)
 at org.jboss.test.kernel.config.support.XMLUtil.<init>(XMLUtil.java:61)
 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:54)
 at org.jboss.test.kernel.config.test.ArrayXMLTestCase.arrayIsInterface(ArrayXMLTestCase.java:77)


                  • Actions
                • 5. Re: Java permissions and JBossXB
                  adrian.brock Oct 19, 2005 5:07 PM (in response to adrian.brock)

                   

                  "scott.stark@jboss.org" wrote:
                  No, the output/classes-tests codebase definitely needs the indicated FilePermission. The codebase of the target file URL is only relevant in terms of matching the security policy FilePermission objects.


                  Yes I know, a class can always read a file/url from its own codebase. :-)


                  My feeling is that the test should have the permission to read the testArrayNotAArray.xml file in order for it to parse it via jbossxb or else you get into the problem of inconsistent access control based on how the file is read.


                  I'm trying to run it without giving the tests any permissions so I can easily spot
                  permission problems.

                  The topology of the codebases is an issue because of our standard separation
                  between output/classes and output/resources.
                  I want to avoid having to jar the tests (which would solve the problem)
                  because if I do that, I can't run the tests inside eclipse very easily :-(

                    • Actions
                  • 6. Re: Java permissions and JBossXB
                    adrian.brock Oct 19, 2005 5:16 PM (in response to adrian.brock)

                    Actually, let's post the real error message :-)

                    <testcase classname="org.jboss.test.kernel.config.test.ArrayXMLTestCase" name="testSimpleArrayFromStrings" time="1.998">
 <error type="java.lang.ExceptionInInitializerError">java.lang.ExceptionInInitializerError
 at org.jboss.util.property.Property.get(Property.java:87)
 at org.jboss.util.platform.Constants.&lt;clinit&gt;(Constants.java:23)
 at org.jboss.util.StringPropertyReplacer.&lt;clinit&gt;(StringPropertyReplacer.java:24)
 at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:440)
 at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:109)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:212)
 at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
 at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:121)
 at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:105)
 at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:85)
 at org.jboss.test.kernel.config.support.XMLUtil.&lt;init&gt;(XMLUtil.java:61)
 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:54)
 at org.jboss.test.kernel.config.test.ArrayXMLTestCase.simpleArrayFromStrings(ArrayXMLTestCase.java:42)
 at org.jboss.test.kernel.config.test.ArrayTestCase.testSimpleArrayFromStrings(ArrayTestCase.java:81)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission java.naming.provider.url read)
 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 at java.security.AccessController.checkPermission(AccessController.java:427)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
 at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
 at java.lang.System.getProperty(System.java:627)
 at org.jboss.util.property.PropertyMap.init(PropertyMap.java:93)
 at org.jboss.util.property.PropertyMap.&lt;init&gt;(PropertyMap.java:73)
 at org.jboss.util.property.PropertyMap.&lt;init&gt;(PropertyMap.java:81)
 at org.jboss.util.property.PropertyManager.&lt;clinit&gt;(PropertyManager.java:57)
 ... 43 more
</error>


                      • Actions
                    • 7. Re: Java permissions and JBossXB
                      starksm64
                      starksm64 Oct 19, 2005 5:16 PM (in response to adrian.brock)

                      Yes, but the problem with this is that you can't actually do very much in the test then because most interesting actions require a permission. The minimum change would be to allow FilePermission read for any content under the output/resources directory. That is a minor change that only adds a very narrow permission grant.

                        • Actions
                      • 8. Re: Java permissions and JBossXB
                        starksm64
                        starksm64 Oct 19, 2005 5:18 PM (in response to adrian.brock)

                         

                        "adrian@jboss.org" wrote:
                        Actually, let's post the real error message :-)

                        Certainly that is an improper escaping of a priviledged action.

                          • Actions
                        • 9. Re: Java permissions and JBossXB
                          adrian.brock Oct 19, 2005 5:23 PM (in response to adrian.brock)

                          What is that PropertyMap/Manager thingy? It seems to be used by the platform constants class.

                            • Actions
                          • 10. Re: Java permissions and JBossXB
                            adrian.brock Oct 19, 2005 5:24 PM (in response to adrian.brock)

                            Bug report: http://jira.jboss.com/jira/browse/JBAS-2386

                              • Actions
                            • 11. Re: Java permissions and JBossXB
                              starksm64
                              starksm64 Oct 19, 2005 5:31 PM (in response to adrian.brock)

                              Some overdone extension to java.util.Properties that adds events. I have no idea why this is being used.

                                • Actions
                              • 12. Re: Java permissions and JBossXB
                                adrian.brock Oct 19, 2005 5:44 PM (in response to adrian.brock)

                                I can see that the SystemPropertiesService uses it.

                                The PropertyManager itself looks like a backdoor to play with system properties.

                                 static {
 // construct default property container and initialze from system props
 props = new PropertyMap();
 props.putAll(System.getProperties());

 // replace system props to enable notifications via System.setProperty()
 System.setProperties(props);
etc.

 public static String getProperty(final String name,
 final String defaultValue)
 {
 return props.getProperty(name, defaultValue);
 }

 public static String setProperty(final String name, final String value) {
 return (String)props.setProperty(name, value);
 }

etc.



                                  • Actions
                                • 13. Re: Java permissions and JBossXB
                                  starksm64
                                  starksm64 Oct 19, 2005 5:51 PM (in response to adrian.brock)

                                  Ok, that seems like nonsense we should get rid of.

                                    • Actions
                                  • 14. Re: Java permissions and JBossXB
                                    adrian.brock Oct 19, 2005 6:00 PM (in response to adrian.brock)

                                    I'm just going to add the permission checking when there is an SM installed
                                    since I don't want to break anybody that is using the listeners.

                                      • Actions
                                    1 2 Previous Next