SQL Server First Responder Kit 中 sp_Blitz 权限检查机制的优化

在 SQL Server 数据库管理中，权限控制是一个至关重要的安全机制。SQL Server First Responder Kit 中的 sp_Blitz 存储过程作为一款广受欢迎的数据库健康检查工具，其权限检查逻辑需要特别严谨。近期发现了一个关于 sys.traces 系统视图访问权限检查的特殊情况，值得数据库管理员和技术专家深入了解。

问题背景

sp_Blitz 在执行过程中会检查 SQL Server 的跟踪日志信息，这需要访问 sys.traces 系统视图。原有的权限检查机制通过 fn_my_permissions 函数来验证用户是否具有 ALTER 权限，这在大多数情况下是有效的。然而，在某些特定权限组合下，这种检查方式会出现问题。

问题重现

当用户同时满足以下三个条件时，sp_Blitz 会出现执行错误：

1. 拥有 VIEW SERVER STATE 权限
2. 是 master 数据库的 db_owner
3. 没有 ALTER TRACE 权限

在这种情况下，虽然 fn_my_permissions 函数返回的结果显示用户具有 ALTER 权限，但实际上用户仍然无法成功查询 sys.traces 视图，导致存储过程执行失败。

技术分析

深入分析权限机制后发现，sys.traces 视图的访问权限检查比表面看起来更为复杂：

1. 权限表象：fn_my_permissions 函数显示 db_owner 角色成员具有 ALTER 权限，这给人造成了权限足够的假象。

2. 实际需求：真正需要的可能是 EXECUTE、RECEIVE 或 VIEW CHANGE TRACKING 等权限，这些权限在 sysadmin 角色中才会显示。

3. 特殊情况：即使是没有特殊权限的用户，如果被授予 ALTER TRACE 权限，fn_my_permissions 可能只显示 SELECT 权限，但实际上可以访问 sys.traces。

解决方案

针对这一特殊情况，提出了更可靠的权限检查方法：直接尝试访问 sys.traces 视图，通过 TRY-CATCH 块捕获可能的权限错误。这种"尝试执行"的方法比查询权限元数据更为准确可靠。

BEGIN TRY
    SELECT 1 FROM sys.TRACES
    SET @SkipTrace = 0;
END TRY
BEGIN CATCH
    SET @SkipTrace = 1;
END CATCH

最佳实践建议

1. 权限授予原则：对于监控工具使用的账户，建议授予明确的 ALTER TRACE 权限，而不是依赖数据库角色继承的权限。

2. 权限验证方法：在开发需要特定权限的存储过程时，考虑使用实际的权限测试而不仅仅是元数据查询。

3. 错误处理：对于关键的系统视图访问，总是实现适当的错误处理机制，确保存储过程在权限不足时能够优雅降级而非完全失败。

这一改进已被合并到 SQL Server First Responder Kit 的开发分支中，将在下一个版本发布。这体现了开源社区通过实际问题解决不断提升工具可靠性的过程。