Contents | Prev | Next | JDBCTM Guide: Getting Started |
These restrictions for untrusted applets are fairly onerous. But they are consistent with the general applet security model and we can see no good way of relaxing them.
However as with applets, if for some reason an untrusted sun.sql.Driver class is loaded from a remote source, then that Driver should only be used with code loaded from that same source.
If JavaSoft proposes a standard for a published protocol for a DBMS-independent JDBC-Net driver, as described in Section 3, then security considerations will be an important factor in the selection of a protocol.
These rules are unnecessary if a driver is downloaded as an applet, because the standard security manager will prevent an applet driver from making illegal connections. However JDBC driver writers should bear in mind that if their driver is "successful" then users may start installing it on their local disks, in which case it becomes a trusted part of the Java environment, and must make sure it is not abused by visiting applets. We therefore urge all JDB driver writers to follow the basic security rules.
These rules all apply at connection open time. This is the point when the driver and the virtual machine should check that the current caller is really allowed to connect to a given database. After connection open, no additional checks are necessary.
However if a JDBC driver wants to share a single TCP connection among several different database connections then it becomes the driver's responsibility to make sure that each of its callers is really allowed to talk to the target database. For example, if we open a TCP connection to the machine foobah for applet A, this does not mean that we should automatically allow applet B to share that connection. Applet B may have no right whatsoever to access machine foobah.
So before allowing someone to re-use an existing TCP connection the JDBC driver should check with the security manager that the current caller is allowed to connect to that machine. This can be done with the following code fragment:
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkConnect(hostName, portNumber);
}
The Security.checkConnect method will throw a java.lang.SecurityException if the connection
is not permitted.
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(fileName);
}
The Security.checkRead method will throw a java.lang.SecurityException if the current caller
is an applet which is not allowed to access the given file.
As with TCP connections, the driver need only be concerned with these security issues if file resources are shared among multiple calling threads and the driver is running as trusted code.
In these circumstances the driver must make "worst case" security assumptions and deny all database access to downloaded applets unless the driver is completely confident that the intended access is innocuous.
For example a JDBC-ODBC bridge might check the meaning of ODBC data source names and only allow an applet to use those ODBC data source names that reference databases on machines to which the applet is allowed to open connections (see 5.4.1 above). But for some ODBC data source names the driver may be unable to determine the hostname of the target database and must therefore deny downloaded applets access to these data sources.
In order to determine if the current caller is a trusted application or applet (and can therefore be allowed arbitrary database access) the JDBC driver can check to see if the caller is allowed to write an arbitrary file:
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkWrite("foobaz");
}