我通过从通用帐户中删除sysadmin权限开始在我们的测试环境中锁定权限。几个开发人员使用的第一个帐户是本地 SQL 登录。我为该帐户赋予了数据库中的db_owner角色。开发人员报告他不能再创建存储过程。
我已经在这个特定的 SQL 2014 实例中验证了这一点,我无法在其他任何地方重现它。我已经做了我能想到的一切来解决这个问题。我得到的最好的线索是我创建了一个新的 SQL 登录名,并在同一个数据库中给了它db_owner 。它也不能创建过程。原始登录无法在其他用户数据库中创建过程,即使它具有db_owner。
尝试创建一个过程会给出:
消息 262,级别 14,状态 18,过程 TheProcedure,第 30 行
CREATE PROCEDURE 权限在数据库“DBTest”中被拒绝。
错误消息是正确CREATE PROCEDURE
的,即使在我明确分配后也不会显示给用户。用户可以更改任何程序。UDF 创建得到类似的错误:
数据库中的 CREATE FUNCTION 权限被拒绝...
有人知道会发生什么吗?
当我做一个:
select * from fn_my_permissions(null, 'DATABASE')
CREATE PROCEDURE
未列出。我检查了 sys.permissions 中的任何DENY
内容,没有。
以下查询:
SELECT * FROM fn_my_permissions('xyz', 'USER');
返回:
IMPERSONATE, VIEW DEFINITION, ALTER, CONTROL
有趣的一个 - 很难把这个固定下来。你有没有想过看公共角色?
sp_helprotect 'CREATE PROCEDURE',NULL,NULL,'s'
这有什么让你回来的吗?
与绕过检查的 sysadmin 不同,内置的数据库角色并没有那么特殊,以至于它们不能被 DENY 覆盖。
尝试查看 Exec sp_helpprotect Null, 'Username' 并查看显示的 DENY 记录。
简短的回答:
尝试将 dev 用户的默认数据库更改为他们的特定数据库。
在 SS Studio 的查询窗口中,确保他们通过数据库下拉列表或 T-SQL USE [DBNAME] 在查询窗口中使用正确的数据库上下文。
长答案:
我不能代表所有情况,但我知道这肯定发生在我们身上的一个案例。对于我们的特定用户,默认数据库设置为“master”,并且具有 SA 权限。我们删除了 SA 权限,结果他们突然无法创建他们需要的程序——只有 CONNECT。
更改用户的默认数据库有助于他们的数据库更正此问题。(事实证明他们只有主数据库的 CONNECT 权限)此外,USE 语句在 SS STudio 查询窗口中工作:
话虽如此,我会检查主数据库(和其他数据库),看看开发人员是否错误地将他们的代码放在其他数据库而不是正确的数据库中——当他们有 SA 时。对我们来说,删除 SA 权利无疑揭示了开发人员如何使用该系统的一个重要问题。
ps 如果他们使用的是部分包含的数据库,请告诉我,因为在数据库内部和外部可能存在相同名称的用户,这会导致类似的、看似基于权限的问题。