必须用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 和应用配置里的文件操作痕迹。
