如何撤销PUBLIC的危险权限_REVOKE EXECUTE ON UTL

必须用revoke execute on sys.utl_file from public撤销public权限，drop会破坏数据库；需先查dba_tab_privs确认权限存在，再检查dba_dependencies识别依赖对象，建议按需授权而非全局撤销。

撤销 public 对 utl_file 的 execute 权限必须用 revoke，不能靠 drop 或禁用包

oracle 中 utl_file 是高危内置包，一旦被 public 拥有 execute 权限，任何数据库用户都可能读写服务器文件系统。撤销动作本身不复杂，但关键在于：它不是“禁用功能”，而是移除授权记录——只要没被 revoke，权限就生效。

必须以具有 DBA 角色或 GRANT ANY OBJECT PRIVILEGE 权限的用户（如 SYS）执行
REVOKE EXECUTE ON SYS.UTL_FILE FROM PUBLIC; 是唯一有效语法；DROP PACKAGE UTL_FILE 会破坏数据库核心功能，绝对禁止
撤销后不会影响已连接会话的当前权限缓存，新会话立即生效，旧会话需重新登录或刷新权限（如执行 ALTER SESSION SET CURRENT_SCHEMA = ... 可能触发重检）

确认 PUBLIC 是否真有 UTL_FILE EXECUTE 权限

别凭记忆或文档操作，先查数据字典。很多人跳过这步，结果 revoke 报 ORA-01927: cannot revoke privileges you did not grant，其实是权限根本不在你手上，或者压根没授过。

运行：

SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'UTL_FILE' AND GRANTEE = 'PUBLIC' AND PRIVILEGE = 'EXECUTE';

如果无结果，说明权限已被撤或从未授予——此时执行 REVOKE 会报 ORA-01927，属正常现象，无需处理
注意区分大小写：UTL_FILE 是大写，dba_tab_privs 视图中 TABLE_NAME 列存储为大写

撤销后要检查依赖对象是否失效

UTL_FILE 被很多老系统、自定义过程、调度作业直接调用。撤销后，这些对象不会自动失效，但运行时抛 PLS-00201: identifier 'UTL_FILE.FOPEN' must be declared 或 ORA-00904: "UTL_FILE"."FOPEN": invalid identifier。

用以下语句找潜在风险对象：

SELECT OWNER, NAME, TYPE FROM DBA_DEPENDENCIES WHERE REFERENCED_NAME = 'UTL_FILE' AND REFERENCED_OWNER = 'SYS';

重点检查 TYPE IN ('PROCEDURE', 'FUNCTION', 'PACKAGE BODY', 'TRIGGER')，尤其是状态为 INVALID 的对象
不要批量编译——先人工评估是否真需要 UTL_FILE，能否改用外部表、UTL_HTTP 或应用层文件处理

替代方案比硬撤销更稳妥：按需授权 + 最小权限原则

直接 REVOKE ... FROM PUBLIC 是最快方式，但生产环境常因“某个报表突然跑不了”引发故障。更可持续的做法是：保留 PUBLIC 无权状态，再为真正需要的用户/角色单独授权。

创建专用角色：CREATE ROLE app_file_writer;，然后 GRANT EXECUTE ON SYS.UTL_FILE TO app_file_writer;
只把该角色授予明确需要文件操作的应用账号，避免扩散到开发、测试等泛用户
限制目录访问：确保 UTL_FILE 只能访问预定义的 ORACLE DIRECTORY 对象，且目录路径不包含 $ORACLE_HOME 或系统关键路径
注意兼容性：Oracle 12c 及以后版本支持在 PDB 级别控制权限，若用多租户，需在每个相关 PDB 内单独执行 REVOKE

最易被忽略的是：撤销后没人验证应用日志写入是否改用其他机制，结果某天归档日志爆满才发现备份脚本里还藏着 UTL_FILE.PUT_LINE。动手前，先翻一遍 cron、DBMS_SCHEDULER 和应用配置里的文件操作痕迹。