对组成链对象的用户权限控制不同于单独访

但是，这个所有权链仍然存在一些安全隐患，主要涉及到以下两个方面。

一是跨越数据库的欺骗访问。假设现在B公司的数据库有一张视图“产品成本”，这个对象的所有者为“Landy”。此时，若A公司的数据库管理员Lance想要非法访问B公司数据库中的“产品成本”这个对象，该如何处理呢?凭借SQL Server的数据库链条，可以很方便的实现这个非法的目的。如数据库管理员Lance在A公司数据库中建立一个用户Landy，并以这个用户的名义建议一个数据库对象，如一张视图。然后让这张视图去调用B公司数据库中的“产品成本”对象。此时，由于这两个数据库对象形成了一个“链条”，其权限控制原则就是按照“所有权”链的原则来处理。由于这两个数据库对象的所有者类似，则用户Lance就具有B公司数据库“产品成本”的访问权了。同理，利用这个原理，A公司的数据库管理员可以拥有B公司数据库中所有对象的访问权限。

这个现象对于大部分企业来说，都是不想看到的。为了解决这一安全隐患，最简单的方法就是不要启用“跨越数据库所有权链”。默认情况下，这是不启用的。可是在实际工作中，数据库管理员为了日常管理的方便，往往会把它开启。此时，数据库管理员就需要在安全与便利上取得一个均衡。

第二个安全隐患是权限的自动赋予。如上面这个例子中，当用户把所有权链中第一个对象“产品成本”的访问权限赋予给Lance后，就意味着用户Landy把这个链条中所有对象的访问权限，如视图或者基础表，赋予给了这个用户。这虽然对数据库管理员来说，大大方便了其管理。但是，却降低了数据库的安全性。

在上面这个例子中，其链条之涉及到三个数据库对象。而在一些中大型的数据库应用中，一个链条锁涉及到的数据库对象往往多达几十个。此时，在采用所有权链的过程中，就需要特别的小心。

笔者以前在数据库设计中，就因为考虑的不够全面，而给用户过多的权利。如用户Lance其虽然具有“产品成本”视图的访问权限。也就是说，用户可以知道某个产品的总成本信息。但是，其不需要知道这个产品的成本构成，不需要知道这个产品材料成本是多少，制造费用是多少。但是，由于这个用户有材料成本的访问权限(通过所有权链的权利寻租实现)，就留下了一定的安全隐患。若这个用户稍微懂一点数据库技术，则就可以通过一定的手段获取这个保密的信息。

所以，在数据库设计中，所有权链是假定对象所有者能够预见到授予对象权限的每个决定的全部后果。但是，这在中大型数据库的设计过程中，往往是不现实的。人的思维毕竟没有计算机那么严密。

为了解决这个安全隐患，笔者的做法是把基础表跟其他对象，如视图，设置为不同的所有者。如此的话，所有权链中对象的权限，就有两个控制的关卡。除了在所有权链条中的第一个对象进行控制之外，还可以在基础表的级别上加一把锁，以实现信息的安全性。