[
https://issues.apache.org/jira/browse/DERBY-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565554#action_12565554
]
Daniel John Debrunner commented on DERBY-3363:
----------------------------------------------
Derby intentionally does not assign any security domain to the generated class
(loader). This is for two reasons:
1) Derby being a library does not assume that all the code in the stack has
permissions to perform any security controlled action, thus it uses privileged
blocks around sensitive operations to allow the privilege to be only granted to
Derby code. Thus there is no need to grant permissions (though a security
domain) to generated code on the stack.
2) Generated code having zero permissions provides a level of security where
remote code installed by a (remote) user cannot perform privileged actions such
as shutting down the vm or opening files, thus bypassing Derby's SQL security.
Thus I think the fix is that code that opens the URL (or creates it?) needs to
be in a privilege block.
> AccessControlException: access denied (java.lang.RuntimePermission
> accessClassInPackage.sun.net.www.protocol.c)
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3363
> URL: https://issues.apache.org/jira/browse/DERBY-3363
> Project: Derby
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.3.2.1
> Environment: ------------------ Java Information ------------------
> Java Version: 1.5.0_11
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jre1.5.0_11
> Java classpath: derby.jar
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: Guo Qiang
> Java user home: C:\Documents and Settings\Guo Qiang
> Java user dir: C:\Repertoire-Server-20080118\RepertoireServer\lib
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> --------- Derby Information --------
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\Repertoire-Server-20080118\RepertoireServer\lib\derby.jar] 10.3.2.1 -
> (59911
> 0)
> Reporter: Song Guo Qiang
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I got one AccessControlException when I tried to backup my derby database
> using code like:
> Statement statement;
> String dbPath;
> ...
> statement.executeUpdate("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE('" + dbPath +
> "')");
> ==
> I run my code with the default security manager installed. The exception
> stack trace is:
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
> accessClassInPackage.sun.net.www.protocol.c)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:151
> 2)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.net.URL.getURLStreamHandler(URL.java:1141)
> at java.net.URL.<init>(URL.java:572)
> at java.net.URL.<init>(URL.java:464)
> at java.net.URL.<init>(URL.java:413)
> at org.apache.derby.impl.store.raw.RawStore.backup(Unknown Source)
> at org.apache.derby.impl.store.access.RAMAccessManager.backup(Unknown
> So
> urce)
> at org.apache.derby.impl.db.BasicDatabase.backup(Unknown Source)
> at
> org.apache.derby.catalog.SystemProcedures.SYSCS_BACKUP_DATABASE(Unkno
> wn Source)
> at
> org.apache.derby.exe.ac3a7f0048x0117xc98bxe062x0000001202800.g0(Unkno
> wn Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown S
> ource)
> at
> org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> So
> urce)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> So
> urce)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown
> Sourc
> e)
> at com.elixirtech.ers2.db.DBSystem.systemUpdate(Unknown Source)
> ==
> I did some quick debug. I guess the problem happens because Derby generates
> some classes on the fly but forgets to assign proper security domains when
> loading the generated classes (such as
> 'org.apache.derby.exe.ac3a7f0048x0117xc98bxe062x0000001202800'). When the
> generated code tried to access some sun.* packages, the security check failed.
> Ideally, Derby code should call
> ClassLoader.defineClass(String name, byte[] b, int off, int len,
> ProtectionDomain protectionDomain)
> instead of
> ClassLoader.defineClass(String name, byte[] b, int off, int len)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
