普通用户不能直接授予ALTER SYSTEM权限来KILL会话，必须用AUTHID CURRENT_USER封装存储过程并校验SID与USER匹配，否则违反最小权限原则且存在越权风险。
普通用户不能直接获得 ALTER SYSTEM 权限来执行 ALTER SYSTEM KILL SESSION，这是 Oracle 的硬性安全限制。唯一可行且被广泛验证的方式是：用调用者权限（AUTHID CURRENT_USER）编写存储过程，封装 kill 逻辑，并只允许用户杀自己 SID 匹配的会话。
为什么不能直接授 ALTER SYSTEM 权限
因为 ALTER SYSTEM 是实例级高危权限，授予后用户不仅能 kill session，还能修改参数、关闭 checkpoint、甚至中止归档——远超“杀自己会话”的最小权限原则。DBA 拒绝授予是合理且必要的。Oracle 官方也明确不提供细粒度的 KILL SESSION 独立权限。
必须用 AUTHID CURRENT_USER 创建过程
否则过程在 SYS 下运行，会绕过用户上下文检查，导致能 kill 任意会话，失去隔离性。正确写法示例如下：
CREATE OR REPLACE PROCEDURE kill_my_session(p_sid NUMBER)
AUTHID CURRENT_USER AS
v_serial# NUMBER;
BEGIN
SELECT SERIAL# INTO v_serial#
FROM V$SESSION
WHERE SID = p_sid AND USERNAME = USER;
<p>EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION ''' || p_sid || ',' || v_serial# || ''' IMMEDIATE';
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE_APPLICATION_ERROR(-20001, 'SID ' || p_sid || ' not found or not owned by ' || USER);
END;-
AUTHID CURRENT_USER确保查询V$SESSION时自动按当前登录用户过滤 - 必须显式加
IMMEDIATE，否则 ACTIVE 会话可能卡在KILLED状态不释放资源 - 不能省略
USER条件校验，否则别人传入自己的 SID 也能触发查询（虽查不到，但逻辑不严谨）
授权与调用要注意的三个坑
过程创建后，DBA 需执行两步授权，缺一不可：
- 对普通用户执行：
GRANT EXECUTE ON sys.kill_my_session TO your_user; - 确保该用户有查询
V$SESSION的权限（通常SELECT_CATALOG_ROLE或显式GRANT SELECT ON V_$SESSION TO your_user；注意是V_$SESSION，不是V$SESSION） - 用户调用时必须带 schema 前缀：
EXEC sys.kill_my_session(123);，否则报PLS-00201: identifier 'KILL_MY_SESSION' must be declared
常见错误是漏掉 V_$SESSION 查询权限，导致过程内部 SELECT 报 ORA-00942: table or view does not exist，而非权限不足提示，容易误判。
别信 DBMS_SESSION.KILL_SESSION 能绕过权限
这个包函数只是 ALTER SYSTEM KILL SESSION 的包装器，底层完全一致，仍需 ALTER SYSTEM 权限。尝试调用 DBMS_SESSION.KILL_SESSION 会直接报 ORA-01031: insufficient privileges，毫无例外。
真正需要控制的是「谁在什么时候杀了谁」——所以生产环境建议在过程里插入审计日志，记录 USER、SYS_CONTEXT('USERENV','HOST')、时间戳和目标 SID，否则事后无法追溯责任。
