5.2. JDBC 和Java应用程序
对于一个普通的Java应用程序（例如全部用Java代码而不是不可靠的applet ）JDBC将从本地的类路
径里面获得驱动，并且允许应用程序自由存取文件，远程服务器等等。但是和applet一样，如果由于
某些原因一个没有验证的sun.sql.Driver类从远程的来源里面获得，那么这个驱动只能和相同地方
来的代码配合。
5.3. Driver的安全责任
JDBC driver可能在各种情况下使用，所以驱动的编制者遵循一定的简单的安全规则，从而避免
applet做非法的数据库连接。如果所有的驱动都象applet一样从网上下载，那么这些原则将是
不必要的，因为普通的安全规则已经对它做了限制。但是驱动的编写者必须记住一旦他们的驱动
获得成功，用户将在本地磁盘安装这些驱动，那么驱动将成为Java环境中一个被信任的部分，所以
必须确信它不会被来访的applet所滥用。所以我们鼓励所有的驱动编写者必须遵循一定安全原则。
所有这些原则都是在连接打开的时候使用。这正式驱动和虚拟机器检查当前调用者是否真的可以与
指定的数据库连接的时刻。一旦连接建立就不必做更多的检查了。
5.3.1. 分享TCP/IP连接的时候必须谨慎
如果一个JDBC驱动试图打开一个 TCP 连接，那么这个打开会被Java 安全管理机制自动检查。
这个机构会检查当前调用栈里面有没有applet，如果有那么就限定它可以访问的机器集合。所
以一般地JDBC驱动可以把TCP建立检查留给Java虚拟机。但是如果一个JDBC驱动试图在多个数据库
连接之间共享一个TCP连接，那么驱动就必须自己负责检查每个调用者是否真的被允许与目标数据库
联系。例如如果我们为applet A打开了一个通往机器foobah 的TCP连接，这并不意味着applet B
被自动允许来共享这个连接。applet B可能没有任何访问机器foobah的权力。所以在允许某个程序
重用一个现成的TCP连接之前，JDBC 驱动必须通过安全机构来检查当前的的调用者是否可以访问这
个连接。通过下面的代码可是实现这个功能。
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkConnect(hostName, portNumber);
}
如果连接是不允许的，那么Security.checkConnect方法将产生一
个java.lang.SecurityException。
5.3.2. 检查所有的本地文件访问
如果一个JDBC取得需要访问本地机器上的数据，那么他必须确
信调用者是被允许打开这个文件的。例如：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkRead(fileName);
}
如果对特定文件的访问是不允许的，那么Security.checkRead方
法将产生一个java.lang.SecurityException。
5.3.3. 作好最坏的准备
一些驱动可能使用本地的方法来桥接底层数据库程序。则这些
情况里面判断那些本地文件将被底层函数所访问是困难的。
在这些环境里面用户必须作好最坏的打算，并且否决所有下载
applet所发出的数据库存取，除非驱动可能完全确信将要做存取
是没有问题的。
例如一个JDBC-ODBC桥接器必须检查ODBC数据源的的名
称，确保applet只可以访问它的“生源地”。如果对有的名字中
不能判断出数据源的主机名，那么只能否决这个访问。
为了决定一个当前的调用者是可以信赖的应用还是一个
applet，JDBC驱动必须能够检查这个调用者是否可以写一个随
机的文件：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkWrite("foobaz");
I. }
