Sybase存储过程动态执行SQL触发X_TABLE_NAME SELECT权限拒绝问题

问题根本原因 #

Sybase对存储过程内的静态SQL和动态SQL采用不同的权限校验规则，这是导致你两个分支执行结果不一致的核心原因：

• 静态SQL（即代码中@X=1分支下的直接SELECT语句）：默认使用存储过程所有者的权限执行，只要所有者对X_TABLE_NAME有SELECT权限，调用者不需要有表权限就能执行成功
• 动态SQL（即EXEC (@sql)包裹的SQL语句）：默认使用调用存储过程的当前登录用户的权限执行，需要当前用户自身对X_TABLE_NAME有SELECT权限，否则就会抛出权限拒绝错误

排查步骤 #

• 先验证静态分支执行结果：将参数@X设为1调用存储过程，若能正常返回数据，即可确认存储过程所有者对X_TABLE_NAME有合法权限，问题确实出在动态SQL的权限校验逻辑
• 检查当前调用用户的表权限：执行系统存储过程sp_helprotect 'X_TABLE_NAME', '你的执行用户名'，查看输出中是否包含SELECT权限的授权记录
• 确认动态SQL拼接正确性：可在EXEC (@sql)前加一句PRINT @sql输出拼接后的完整SQL，确认表名拼写、schema前缀没有错误，排除表名识别错误导致的权限误报

修复方案 #

• 方案1：直接给执行用户授权（适合允许用户直接访问表的场景）
  执行授权命令即可：

  GRANT SELECT ON X_TABLE_NAME TO 执行存储过程的用户名
  

• 方案2：指定存储过程用所有者权限执行（适合不想给用户开放表直接访问权限的场景）
  创建/修改存储过程时添加WITH EXECUTE AS OWNER参数，这样存储过程内的所有SQL包括动态SQL都会统一使用所有者的权限执行，不需要给调用用户单独开表权限：

  CREATE PROCEDURE 你的存储过程名
      @X INT,
      @COLUMNS NVARCHAR(1000)
  WITH EXECUTE AS OWNER -- 新增这一行配置
  AS
  -- 后续保留原有逻辑即可
  

• 方案3：替换动态SQL为静态实现（适合@COLUMNS为固定可选范围的场景）
  如果@COLUMNS的取值是预先定义好的几个枚举值，可以用CASE语句实现列的动态选择，完全避免动态SQL，同时规避SQL注入风险。

注意：你的现有实现直接拼接用户传入的@COLUMNS参数存在SQL注入风险，若必须使用动态SQL，建议提前对@COLUMNS的内容做合法性校验，禁止出现非法字符。

内容的提问来源于stack exchange，提问作者Karen