在SQL SERVER 2005/2008中拥有一个对象

jokerchu

　　在SQL SERVER 2005/2008中拥有一个对象

从SQL SERVER2000升级到2005/2008后，一个我们必须重新认识的情况是对象不再有所有者（owner）。架构包含对象，架构有所有者。如果你查询表sys.objects，你将会看到这看起来是正确的，只是表中还有一个字段principal_id，但是一般情况下它总是NULL值。不久前一天，我突然对principal_id字段的表示了疑惑：为什么要存在这个字段呢?我又仔细地看了联机帮助sys.objects的解释：
“如果不是架构所有者，则为单个所有者的 ID。默认情况下，架构包含的对象由架构所有者拥有。不过，通过使用 ALTER AUTHORIZATION 语句更改所有权可以指定备用所有者。”

换句话说，对象现在还可以被一个用户所拥有。但是“备用所有者”又让我打住了，这什么意思呢？让我们先建立一个测试环境：我们需要在两个不同架构中创建两个对象。这些架构属于不同的所有者，当然我们还需要一个测试者，所以还需要一个第三者。让我们搭起这个环境吧：
CREATE USER User1 WITHOUT LOGIN;
GO
CREATE USER User2 WITHOUT LOGIN;
GO
CREATE USER User3 WITHOUT LOGIN;
GO

/* 创建两个架构，并让它属于不同的用户*/
CREATE SCHEMA User1 AUTHORIZATION User1;
GO
CREATE SCHEMA User2 AUTHORIZATION User2;
GO
/* 核查一下架构，看它是否被不同架构所拥有*/
SELECT schema_id, [name], USER_NAME(principal_id) [Owner]
FROM sys.schemas
WHERE LEFT([name], 4) = 'User';
GO
现在我们已经有了用户和架构，我们再创建一个表和一个引用该表的存储过程。这两个对象分属不同的架构。这就是说没有形成所有权链。
/* 在user1架构上创建一个表。*/
CREATE TABLE User1.MyTable (Number INT);
GO
INSERT INTO User1.MyTable (Number) VALUES (1);
INSERT INTO User1.MyTable (Number) VALUES (2);
INSERT INTO User1.MyTable (Number) VALUES (3);
GO

/* 在user2架构中创建一个存储过程。因为user1和user2这两个架构属于不同的用户，所以不能形成所有权链。*/
CREATE PROC User2.MyProc
AS
BEGIN
SELECT Number FROM User1.MyTable;
END;
GO

/* 授权我们的试验用户user3执行存储过程的能力。除此之外，user3没有任何权利，尤其是在user1.MyTable没有权利 */
GRANT EXECUTE ON OBJECT::User2.MyProc TO User3;
GO

/* 核查一下我们刚刚创建的架构和对象和“所有者”，注意“所有者”一列会显示"--No Owner--." */
SELECT
OBJECT_ID, SCHEMA_NAME(schema_id)[Schema], [name],
COALESCE(USER_NAME(principal_id),'--No Owner--') [Owner]
FROM sys.objects
WHERE LEFT([name], 2) = 'My';
GO
现在来测试一下，看看user3是否能成功地执行存储过程。
/* 在User3上下文中执行存储过程，此时会报错说user3没有在user1.MyTable表上的SELECT权限。 */
EXECUTE AS USER = 'User3';
GO

EXEC User2.MyProc;
GO

REVERT;
GO
这个错误告诉我们一个所有权链并没有形成。这是预料中的事。但是假如我们对user1.MyTable使用ALTER AUTHORIZATION会怎么样呢？
/* 让我们将User1.MyTable的所有权给User2用户*/
ALTER AUTHORIZATION ON OBJECT::User1.MyTable TO User2;
GO
/*重新查询一下架构，发现其所有权并没有改变*/
SELECT schema_id, [name], USER_NAME(principal_id) [Owner]
FROM sys.schemas
WHERE LEFT([name],4)='User';
GO

/* 重新查询一下对象，注意User1.MyTable已经有所有者了——User2，这表明所有权链已经形成。 */
SELECT OBJECT_ID, SCHEMA_NAME(schema_id)[Schema], [name],
COALESCE(USER_NAME(principal_id), '--No Owner--') [Owner]
FROM sys.objects
WHERE LEFT([name], 2) = 'My';
GO
现在当我们执行存储过程是，它运行了。所有权链形成了。
/* User3下重新执行存储过程，这次成功了。所有权链形成了*/
EXECUTE AS USER = 'User3';
GO

EXEC User2.MyProc;
GO

REVERT;
GO
但是这儿有一个有趣的情形：在user1架构中的其他对象情况如何呢？他们和表形成所有权链了吗？答案是否定的，下面的脚本将会展示。
/* 现在在User1架构下创建一个存储过程，看看是否形成了所有权链*/
CREATE PROC User1.AnotherProc
AS
BEGIN
SELECT Number FROM User1.MyTable;
END;
GO

/* 授权USER3用户执行存储过程的能力，这样我们就可以测试了。*/
GRANT EXECUTE ON OBJECT::User1.AnotherProc TO User3;
GO

/* 当我们执行存储过程时，我们得到无SELECT权限的错误。*/
EXECUTE AS USER = 'User3';
GO
EXEC User1.AnotherProc;
GO
REVERT;
GO

说句心里话，我一点也不喜欢这种能力。实际上，这种能力在联机帮助中也并没有说很多，而且我知道在SQL SERVER2005中当对象的所有者转移后会引起很多混乱。当你考虑以下的话，你会发现它是有道理的：缺省情况下，对象的所有者就是架构的所有者。一个对象如果没有特地为它指定所有者，那么架构的所有者就是对象的所有者。但是对象是可以拥有一个所有者的。

这无故地增添了混乱。从安全角度来讲，这就是说我们需要既检查对象和又检查架构的所有权，并在此基础上考虑所有权链。同时，这样增加了潜在的威胁性：特别是一些人为了实现所有权链而随手“一次性”地将对象指定一个所有者。我比较喜欢在架构层次上形成所有权链。但是，不是所有事都能遂愿的，这就要求我们在审视数据库安全时——尤其是所有权链时——要知道还有“对象所有者”这么一回事。

原文地址：
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/03/04/owning-an-object-in-sql-server-2005-2008.aspx