是否应对SQL Server 2005中的存储过程赋予CONTROL权限？

Question

我遇到了一个问题，即在SQL Server 2005中的特定存储过程上授予EXECUTE权限不起作用。一些测试人员弄乱了权限 - 并发现如果他们还在存储过程中授予了CONTROL权限 - 那么它运行正常。他们现在确信授予CONTROL权限是可行的方法。

我知道这不可能是真的 - 事实上我认为真正的问题是用户没有对存储过程运行的表的选择/插入/更新/删除权限。问题是，我似乎无法在网上找到任何证明它的东西。

我说错了吗？是否有人知道任何有关此事的文件？

提前致谢。

回复评论的更多信息： 存储过程正在执行多次删除。它首先删除将被删除的“主”记录孤立的所有记录，然后最终删除父记录。

此外，我们看到的错误表明用户没有足够的权限 - 或者存储过程不存在。我们已经确认我们正在使用正确的用户，并且该用户已获得EXECUTE权限。

Answer 1

如果存储过程是使用EXECUTE AS CALLER（我认为是默认值）创建的，那么调用者必须拥有执行存储过程所需的所有权限以及该过程的EXECUTE。

从EXECUTE AS的SQL Server文档：

  

CALLER指定里面的语句   模块在上下文中执行   模块的调用者。用户   执行模块必须有   适当的权限不仅仅是   模块本身，但也任何   引用的数据库对象   由模块。

请注意，由于SQL Server使用所有权链处理权限检查的方式，这并不总是严格正确，我猜测授予过程控制权（赋予被授予者所有权状态）会导致这些权限检查被绕过。

如果使用EXECUTE AS OWNER创建过程，则不需要在该过程上授予除EXECUTE之外的任何权限。

Answer 2

执行应该是所有需要的。

存储过程是否正在访问位于数据库外的表？

如果是这样，请尝试在存储过程在同一数据库之外使用的表上设置适当的用户权限。

Answer 3

如果您只需要能够执行存储过程，那么很明显，CONTROL权限不是的方式。是的，它的工作方式与在本地系统帐户下运行您的网站的方式相同。

如果EXECUTE权限的授予者也是受影响的表的所有者，那么执行sp应该没有问题。否则，您应该授予显式权限或考虑使用ALTER AUTHORIZATION语句调整所有权。

对于奖励可管理性，请创建数据库角色以应用显式权限，而不是直接将其分配给用户。

Answer 4

这可能已经解决了，但在我的情况下，我需要授予控制权限（在测试服务器上，而不是实时服务器上）的原因是因为存储过程的原始开发人员在设计它时错过了GO语句所以GRANT EXECUTE行在存储过程中。我们在现场修复了它，但看起来修复从未在测试中实现过。