pl/sql中检查表select权限最可靠方式是动态执行查询并捕获ora-00942（无表或无权限）和ora-01031（权限不足）异常；对象级权限无法通过session_privs等视图准确反映，且需防范sql注入。
pl/sql里怎么检查当前用户有没有某张表的select权限
直接查 session_privs 或 role_sys_privs 不够——它们只反映角色授予的系统权限，不体现对象级权限（比如对 employees 表的 select）。真正可靠的方式是尝试访问并捕获异常：
DECLARE
l_count NUMBER;
BEGIN
EXECUTE IMMEDIATE 'SELECT COUNT(*) FROM employees WHERE ROWNUM = 1' INTO l_count;
DBMS_OUTPUT.PUT_LINE('有 SELECT 权限');
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('有 SELECT 权限（但表空）');
WHEN OTHERS THEN
IF SQLCODE = -942 THEN
DBMS_OUTPUT.PUT_LINE('ORA-00942：无此表或无 SELECT 权限');
ELSIF SQLCODE = -1031 THEN
DBMS_OUTPUT.PUT_LINE('ORA-01031：权限不足（可能缺 SELECT ANY TABLE）');
ELSE
RAISE;
END IF;
END;
-
NO_DATA_FOUND不代表没权限，只说明没数据；得靠ORA-00942（表或视图不存在）和ORA-01031（权限拒绝）来区分真实权限缺失 - 别用
ALL_TAB_PRIVS查当前会话权限——它依赖数据字典缓存，且不包含通过角色间接获得的对象权限（除非启用SET ROLE） - 如果目标表名来自参数，必须做白名单校验或使用
DBMS_ASSERT.SQL_OBJECT_NAME防注入
如何在存储过程中动态校验「用户能否更新某条记录」
对象权限（如 UPDATE）是表级的，行级控制得靠业务逻辑。常见做法是在 UPDATE 前加 WHERE 子句限定可操作范围，并检查是否真的改到了行：
PROCEDURE update_salary(p_emp_id NUMBER, p_new_sal NUMBER) IS
l_rows_updated NUMBER;
BEGIN
UPDATE employees
SET salary = p_new_sal
WHERE employee_id = p_emp_id
AND department_id = SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA'); -- 示例：只允许改本部门数据
<p>l_rows_updated := SQL%ROWCOUNT;
IF l_rows_updated = 0 THEN
RAISE_APPLICATION_ERROR(-20001, '无权修改该员工（ID=' || p_emp_id || '）');
END IF;
END;</p>
- 别依赖
CURRENT_USER判断归属——它返回定义者权限用户，不是调用者；用SYS_CONTEXT('USERENV', 'SESSION_USER')或自定义应用上下文更稳妥 - WHERE 中硬编码条件易出错，建议把行级规则抽象成函数，比如
can_access_employee(p_emp_id)返回布尔值 - 注意触发器或策略（VPD）可能已拦截了 UPDATE，此时
SQL%ROWCOUNT为 0，但错误码未必是 -20001
为什么用 AUTHID DEFINER 的过程无法读取调用者有权限的表
因为 AUTHID DEFINER（默认）下，PL/SQL 执行时只使用定义者的权限，不继承调用者的对象权限。即使调用者被直接授予了 SELECT ON orders，过程内部仍会报 ORA-00942。
- 解决方案一：改用
AUTHID CURRENT_USER，让过程以调用者身份执行（但要求调用者有所有涉及对象的权限） - 解决方案二：定义者显式授予所需权限（
GRANT SELECT ON orders TO pkg_owner），再用AUTHID DEFINER - 混合场景（如部分表需调用者权限、部分需定义者权限）只能拆成两个子程序，或用动态 SQL +
EXECUTE IMMEDIATE并配合WITH GRANT OPTION授权链
容易被忽略的权限校验盲区
很多人只盯着 DML 权限，却忘了这些隐式依赖：
- 调用
UTL_HTTP或UTL_FILE前，必须通过DBMS_NETWORK_ACL_ADMIN配置网络 ACL，否则报ORA-24247，和对象权限无关 - 查询
V$SESSION等动态性能视图，需要SELECT_CATALOG_ROLE或直接授SELECT ON v_$session（注意带下划线的基表名） - 使用
DBMS_METADATA.GET_DDL获取其他用户对象 DDL 时，需SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY，仅对象权限不够 - 自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）里执行的语句，权限上下文独立，需单独确认其内操作的权限有效性
权限问题往往不是“有没有”，而是“在哪一层失效”——数据字典、网络层、动态视图、自治事务，都可能成为断点。动手前先用 SELECT * FROM SESSION_ROLES 和 SELECT * FROM SESSION_PRIVS 快速确认当前会话明面权限，再针对性排查。
