Hi Mike,
Glad to hear that this worked for you. A couple comments inline...
On 9/28/18 4:33 AM, Michael Remijan wrote:
Hi Rick,
Thanks again for replying to question.
I finally had some time to sit down and take a look at this. I’m happy
to say that with what you sent me*, I was able to get Derby running
under the security manager and everything is working!* I did have to
make a few updates to get everything working.
1. SocketPermission
My Derby server is accessed by remote clients. I use
-Dderby.drda.host=0.0.0.0 to override the default localhost-only
interface listening. In terms of updates, I had to add in the
following permission in addition to the localhost permission you
mention below:
permission java.net.SocketPermission "${derby.drda.host
}:${derby.security.port}", "connect,resolve";
I was testing database shutdown and backup and I don’t remember which
of those two processes were failing without this permission. But I
think it was shutdown.
2. FilePermission
My backup processes uses CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE
(‘/tmp/resiste-backup/1527’). So the derby.jar file needed
read,write,delete permissions to the /tmp directory on the filesystem
so it could write out the backup into that directory. I added the
following file permission:
permission java.io.FilePermission "/tmp${/}-", "read,write,delete";
Unlike the SocketPermission above, which I think would affect many
users, this file permission is specific to how I’m doing things. I
could have chosen to write the backup to another directory, but this
is the process I have setup to meet my requirements. So no big deal on
this one.
My instinct is to only grant Derby access to directories which are owned
by the user who started the server or by the database owner. /tmp is ok
if you don't mind many people reading your Derby-managed data.
3. SQLPermission
The final update I made was an SQLPermission. When administering my
Derby database with the the `ij` tool, found an exception in the
derby.log file about deregisterDriver. So I added this permission to
the derby.jar file as well:
permission java.sql.SQLPermission "deregisterDriver";
This is an annoying bit of noise in the diagnostic log. Usually, it's
harmless. The database does shutdown safely even when the Derby JDBC
driver can't be unloaded. The downside of failing to unload the driver
is that the Derby classes can't be garbage collected.
Cheers,
-Rick
So those were my updates. At some point I am going to create a blog
article about this which outlines everything. When I do, I will be
sure to reference you since you were a big help getting this going.
Mike
*From:*Rick Hillegas <[email protected]>
*Sent:* Monday, August 20, 2018 9:02 PM
*To:* [email protected]
*Subject:* Re: Need help with security policy
Hey Mark,
I have reproduced some of your security policy problems with Derby
10.14.2.0 on Java 11. I used the server.policy bundled with the
product. I had to adjust the policy file as follows:
1) Grant derbynet.jar the following additional permissions:
permission java.util.PropertyPermission "derby.*", "read,write";
permission java.net.SocketPermission
"localhost:${derby.security.port}", "connect,resolve";
2) Grant derbytools.jar the following additional permission:
permission java.util.PropertyPermission "*", "read,write";
3) Grant derbyclient.jar the following additional permission:
permission java.net.SocketPermission
"localhost:${derby.security.port}", "connect,resolve";
With those adjustments, the experiments ran successfully. I have
attached the files which I used for these experiments:
zstart - script to boot the server
zij - script to run a simple ij script using the client driver
zstop - script to shutdown the server
zz.policy - policy file used by all of the scripts
Hope this helps,
-Rick
On 8/20/18 5:49 AM, Michael Remijan wrote:
Hi Derby users.
I need some help getting the security policy right.
First, here is the command line with all the options for when I
start Derby. I’m pretty sure I got all these correct.
/home/derby/opt/java/bin/java -Dderby.drda.host=0.0.0.0
-Dderby.drda.portNumber=1527
-Dderby.system.home=/var/local/derby/1527
-Dderby.install.url=file:/home/derby/opt/derby/lib/
<file://home/derby/opt/derby/lib/> -Djava.security.manager
-Djava.security.policy=/var/local/derby/1527/security.policy
-classpath
/home/derby/opt/derby/lib/derby.jar:/home/derby/opt/derby/lib/derbynet.jar:/home/derby/opt/derby/lib/derbytools.jar:/home/derby/opt/derby/lib/derbyoptionaltools.jar:/home/derby/opt/derby/lib/derbyclient.jar
org.apache.derby.drda.NetworkServerControl start
My Java version is:
OpenJDK 64-Bit Server VM Zulu11.1+23 (build 11-ea+22, mixed mode)
My Derby version is:
10.14.2.0
My Derby sysinfo is:
------------------ Java Information ------------------
Java Version: 11-ea
Java Vendor: Azul Systems, Inc.
Java home: /opt/zulu11.1+23-ea-jdk11-linux_x64
Java classpath:
/home/derby/opt/derby/lib/derby.jar:/home/derby/opt/derby/lib/derbynet.jar:/home/derby/opt/derby/lib/derbytools.jar:/home/derby/opt/derby/lib/derbyoptionaltools.jar:/home/derby/opt/derby/lib/derbyclient.jar
OS name: Linux
OS architecture: amd64
OS version: 4.15.0-20-generic
Java user name: derby
Java user home: /home/derby
Java user dir: /opt/db-derby-10.14.2.0-bin/bin
java.specification.name: Java Platform API Specification
java.specification.version: 11
java.runtime.version: 11-ea+22
--------- Derby Information --------
[/opt/db-derby-10.14.2.0-bin/lib/derby.jar] 10.14.2.0 - (1828579)
[/opt/db-derby-10.14.2.0-bin/lib/derbytools.jar] 10.14.2.0 - (1828579)
[/opt/db-derby-10.14.2.0-bin/lib/derbynet.jar] 10.14.2.0 - (1828579)
[/opt/db-derby-10.14.2.0-bin/lib/derbyclient.jar] 10.14.2.0 -
(1828579)
[/opt/db-derby-10.14.2.0-bin/lib/derbyoptionaltools.jar] 10.14.2.0
- (1828579)
------------------------------------------------------
----------------- Locale Information -----------------
------------------------------------------------------
------------------------------------------------------
I copied the demo file from /demo/templates/server.policy/ and I
use it as my //var/local/derby/1527/security//./ The only change I
made to the demo file was to **uncomment** the following permission:
permission java.io.FilePermission "<<ALL FILES>>",
"read,write,delete";
After running Derby with this security policy (see attached), the
Derby network server is able to start fine and I can connect
remote clients successfully. However, I have 2 problems which I
haven’t been able to resolve.
(1)
The first big problem is I cannot shutdown the the Derby network
server while it’s running the security policy! Here is the
commanline of the shutdown command:
derby 5503 5498 0 07:43 pts/2 00:00:00
/home/derby/opt/java/bin/java -Dderby.drda.host=0.0.0.0
-Dderby.drda.portNumber=1527
-Dderby.system.home=/var/local/derby/1527
-Dderby.install.url=file:/home/derby/opt/derby/lib/
<file://home/derby/opt/derby/lib/> -Djava.security.manager
-Djava.security.policy=/var/local/derby/1527/security.policy
-classpath
/home/derby/opt/derby/lib/derby.jar:/home/derby/opt/derby/lib/derbynet.jar:/home/derby/opt/derby/lib/derbytools.jar:/home/derby/opt/derby/lib/derbyoptionaltools.jar:/home/derby/opt/derby/lib/derbyclient.jar
org.apache.derby.drda.NetworkServerControl shutdown
Here is the StackTrace I get trying to shutdown:
Mon Aug 20 07:43:45 CDT 2018 : access denied
("java.net.SocketPermission" "0.0.0.0:1527" "connect,resolve")
java.security.AccessControlException: access denied
("java.net.SocketPermission" "0.0.0.0:1527" "connect,resolve")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.base/java.security.AccessController.checkPermission(AccessController.java:895)
at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at
java.base/java.lang.SecurityManager.checkConnect(SecurityManager.java:824)
at java.base/java.net.Socket.connect(Socket.java:586)
at java.base/java.net.Socket.connect(Socket.java:540)
at java.base/java.net.Socket.<init>(Socket.java:436)
at java.base/java.net.Socket.<init>(Socket.java:246)
at
java.base/javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:277)
at
org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(Unknown
Source)
at
org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(Unknown
Source)
at java.base/java.security.AccessController.doPrivileged(Native
Method)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.setUpSocket(Unknown
Source)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.shutdown(Unknown
Source)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown
Source)
at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
Any help with this permission problem would be greatly appreciated.
(2)
When I try to run a database backup, I get a file permission
exception.
Exception in thread "main" java.security.AccessControlException:
access denied ("java.io.FilePermission"
"/tmp/resiste-backup/1527/resiste-backup.sql" "read")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.base/java.security.AccessController.checkPermission(AccessController.java:895)
at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at
java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
at java.base/java.io.FileInputStream.<init>(FileInputStream.java:146)
at java.base/java.io.FileInputStream.<init>(FileInputStream.java:112)
at org.apache.derby.impl.tools.ij.Main$1.run(Unknown Source)
at org.apache.derby.impl.tools.ij.Main$1.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native
Method)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
I’m surprised at this exception because I specifically set the
permission in my security.policy file /permission
java.io.FilePermission "<<ALL FILES>>", "read,write,delete";/
So I’m not sure what’s going on with this exception either. Any
help would be appreciated.
Mike
@mjremijan
