Basic Network Server security policy

If you boot the Network Server without specifying a security manager, the Network Server will install a default Java security manager enforcing a Basic policy. This happens if you boot the Network Server as your VM's entry point, e.g.:

java org.apache.derby.drda.NetworkServerControl start ...

Note that you should run your Network Server with user authentication enabled. For details on how to enable user authentication, please see "Working with user authentication" in the Derby Developer's Guide.

Some of your application code may run as procedures and functions which you have declared using the CREATE PROCEDURE and CREATE FUNCTION statements. You will need to add privileged blocks to your declared procedures and functions if they perform sensitive operations such as file and network i/o, classloading, system property reading, etc.

If for some reason you do not want to run your client/server application under a security manager, you may override the Network Server's impulse to install a default policy. For details, see Running the Network Server without a security policy.

Note that the Network Server attempts to install a security manager only if you boot the server as the entry point of your VM. The Network Server will not attempt to install a security manager if you start the server from your application using the programmatic API described in the following section: Starting the Network Server from a Java application.

You will find a template security policy in the Derby distribution at demo/templates/server.policy. Most likely, you will want to customize this policy. For example, probably you will want to restrict the server's liberal file i/o permissions which let the server backup/restore and export/import to or from any location in the local file system. For details on how to customize the Template policy, please see Customizing the Network Server's security policy. The following example is a copy of the Basic policy:

grant codeBase "${derby.install.url}derby.jar"
{
//
// These permissions are needed for everyday, embedded Derby usage.
//
  permission java.lang.RuntimePermission "createClassLoader";
  permission java.util.PropertyPermission "derby.*", "read";
  // The next two properties are used to determine if the VM is 32 or 64 bit.
  permission java.util.PropertyPermission "sun.arch.data.model", "read";
  permission java.util.PropertyPermission "os.arch", "read";
  permission java.util.PropertyPermission "user.dir", "read";
  permission java.util.PropertyPermission "derby.storage.jvmInstanceId", 
      "write"; 
  permission java.io.FilePermission "${derby.system.home}","read";
  permission java.io.FilePermission "${derby.system.home}${/}-", "read,write,delete";

//
// This permission lets you backup and restore databases
// to and from arbitrary locations in your file system.
//
// This permission also lets you import/export data to and from
// arbitrary locations in your file system.
//
// You may want to restrict this access to specific directories.
//
  permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
};

grant codeBase "${derby.install.url}derbynet.jar"
{
//
// This permission lets the Network Server manage connections from clients.
//

// Accept connections from any host. Derby is listening to the host
// interface specified via the -h option to "NetworkServerControl
// start" on the command line, via the address parameter to the
// org.apache.derby.drda.NetworkServerControl constructor in the API
// or via the property derby.drda.host; the default is localhost.
// You may want to restrict allowed hosts, e.g. to hosts in a specific
// subdomain, e.g. "*.acme.com".

  permission java.net.SocketPermission "*", "accept"; 
};