I have already posted a number of blogs about Derby:<\/p>\n
This wasn’t intended to be a series. But over the years I’ve been using Derby more and more. I started using Derby as my database of choice for my Microservice architecture. These are personal-use applications, so Derby is more than sufficient. Even though these are personal-use applications, I require multiple servers<\/a> with limited user permissions<\/a>, and of course database backup and restoration<\/a>. The final requirement is security. I run my Derby databases on an Ubuntu Linux VM with the This post is solely informative. Critically think before using any information presented. Learn from it but ultimately make your own decisions at your own risk.<\/p>\n I did all of the work for this post using the following major technologies. You may be able to do the same thing with different technologies or versions, but no guarantees.<\/p>\n I am not going to go through the process of downloading and installing these technologies. I’ll leave that as an exercise for you.<\/p>\n NOTE<\/strong> Starting with version 10.15, the Derby project has been updated to use the Java 9 module system. As a result, the JAR files have changed quite a bit. It’s unlikely the security.policy below will work with version 10.15+. As of this blog’s publication date, I’ve yet to try it.<\/p>\n In order to manage Derby to run with a Java security policy, you need 3 scripts. The 1st script will setup the setup environment variables to configure Derby. The 2nd script will start the Derby network server, passing the correct command line parameters. The 3rd will stop the Derby network server.<\/p>\n Listing 1.1 shows you the first of these scripts. It exports a number of system environment variables with configuration values specific to run Derby in your environment.<\/p>\n DERBY_HOME<\/strong> is self explanatory. It’s where Derby is unzipped (installed). Add Derby’s JAVA_HOME<\/strong> is self explanatory. It’s where Java is unzipped (installed). Add Java’s NS_HOME<\/strong> is “N<\/strong>etwork S<\/strong>erver Home”. This is the directory the Derby network server will use to store its configuration and databases. Whenever a new database is created on this Derby network server, a new sub-directory will be created under NS_PORT<\/strong> is “N<\/strong>etwork S<\/strong>erver Port”. It’s the port the Derby network server uses to listen for connections. This allows multiple Derby network servers to run on the same host.<\/p>\n NS_HOST<\/strong> is “N<\/strong>etwork S<\/strong>erver Host”. It sets the network interface used by the Derby network server when listening for connections. By default, the Derby network server only listens for connections on the loopback address of DERBY_OPTS<\/strong> is the system property used to get all of the configuration options to Derby. Its value is created by concatenating together the appropriate Derby system properties with their associated values. The first 3 properties are needed to start Derby with or without a security policy.<\/p>\n The final 5 properties are needed for configuring Derby to run with a security policy.<\/p>\nderby<\/code> usr account. Although the derby<\/code> usr account has limited permissions on the VM, any extra layer of security is good. So the purpose of this blog is to demonstrate how to run Derby with a Java security policy<\/strong> to limit the JVM’s permissions and enhance runtime security.<\/p>\nDisclaimer<\/h2>\n
Requirements<\/h2>\n
\n
Linux bash scripts<\/h2>\n
Listing 1.1 – setenv.sh<\/h2>\n
\n\n
\n \n \n #!\/bin\/bash<\/code><\/div>\nexport DERBY_HOME=\/home\/derby\/opt\/derby<\/code><\/div>\nexport PATH=<\/code>\"$DERBY_HOME\/bin:$PATH\"<\/code><\/div>\necho <\/code>\"DERBY_HOME=$DERBY_HOME\"<\/code><\/div>\nexport JAVA_HOME=\/home\/derby\/opt\/java<\/code><\/div>\necho <\/code>\"JAVA_HOME=$JAVA_HOME\"<\/code><\/div>\nexport NS_HOME=\/var\/local\/derby\/<\/code>1527<\/code><\/div>\nmkdir -p $NS_HOME<\/code><\/div>\necho <\/code>\"NS_HOME=$NS_HOME\"<\/code><\/div>\nexport NS_PORT=<\/code>1527<\/code><\/div>\necho <\/code>\"NS_PORT=$NS_PORT\"<\/code><\/div>\nexport NS_HOST=<\/code>0.0<\/code>.<\/code>0.0<\/code><\/div>\necho <\/code>\"NS_HOST=$NS_HOST\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.drda.host=$NS_HOST\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.drda.portNumber=$NS_PORT\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.system.home=$NS_HOME\"<\/code><\/div>\n# Security Policy<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.stream.error.logSeverityLevel=0\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.security.port=$NS_PORT\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Dderby.install.url=file:$DERBY_HOME\/lib\/\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Djava.security.manager\"<\/code><\/div>\nexport DERBY_OPTS=<\/code>\"$DERBY_OPTS -Djava.security.policy=$NS_HOME\/security.policy\"<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\nbin<\/code> directory to the PATH<\/code>.<\/p>\nbin<\/code> directory to the PATH<\/code>.<\/p>\nNS_HOME<\/code> for the new database. This allows multiple Derby network servers running on the same host to keep their data separate.<\/p>\n127.0.0.1<\/code>. This default means clients must run on the same host as the network server – not very useful. By setting the host to 0.0.0.0<\/code>, the Derby network server will listen for connections on any network interface on the host. If your VM has multiple network interfaces, NS_HOST<\/code> should be set to the IP of one of those interfaces. Setting this value allows clients to be remote.<\/p>\n\n