在SQL Server 2005中，是否应该授予存储过程的CONTROL权限？

Question

我遇到一个问题，即在SQL Server 2005中授予特定存储过程的EXECUTE权限无效。一些测试人员搞乱了权限，并发现如果他们还授予存储过程的CONTROL权限，则可以正常运行。他们现在确信授予CONTROL权限是正确的方法。

我知道这不可能是真的，实际上我认为真正的问题是用户没有对存储过程所涉及的表具有选择/插入/更新/删除权限。问题是，我似乎找不到任何在线文档来证明它。

我是正确的吗？是否有人知道任何讨论此问题的文档？

谢谢。

- leftend

---

如果您给存储过程授予执行权限，它可以随意进行所有的插入、更新和删除操作。您需要告诉我们存储过程还做了什么。 - Robert C. Barth

哦，对不起...很抱歉。这个存储过程正在执行多个删除操作。它首先删除所有将被“主”记录删除而变成孤立记录的记录，最后再删除父记录。 - leftend

此外，我们看到的错误提示是用户没有足够的权限 - 或存储过程不存在。我们已经确认我们正在使用正确的用户，并且该用户已被授予执行权限。 - leftend

Answer 1

如果使用EXECUTE AS CALLER创建存储过程（我相信这是默认设置），则调用者除了对该存储过程具有执行权限之外，还必须拥有执行存储过程所需的所有权限。从SQL Server关于EXECUTE AS的文档中可以看到：

CALLER指定模块内的语句在模块的调用者上下文中执行。执行该模块的用户不仅必须对模块本身具有适当的权限，还必须对任何被模块引用的数据库对象具有适当的权限。

请注意，由于SQL Server使用所有权链处理权限检查的方式，这并不总是严格正确的，我猜测授予过程CONTROL权限（将所有权状态授予受让人）会绕过这些权限检查。

如果使用EXECUTE AS OWNER创建过程，则无需授予除EXECUTE on the procedure之外的任何权限。

- Eric Rosenberger

Answer 2

只需要执行即可。

存储过程是否访问了其所在数据库之外的表格？

如果是这样，请尝试为存储过程使用的位于不同数据库之外的表格设置适当的用户权限。

- K Richard

Answer 3

如果您只需要能够执行存储过程，那么显然 CONTROL 权限并不是正确的方法。是的，它可以工作，就像在本地系统帐户下运行网站一样。

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

为了更好的可管理性，请创建一个数据库角色来应用明确的权限，而不是直接分配给用户。

- Thuglife

Answer 4

这个问题可能已经得到解决了，但在我的情况下，我需要授予控制权限（在测试服务器上，而不是实际的服务器），因为存储过程的原始开发人员在设计时遗漏了一个GO语句，导致GRANT EXECUTE行位于存储过程内部。我们在实际服务器上修复了这个问题，但似乎在测试服务器上没有实施这个修复。

- BMG002