User Authority Check... .

本文详细介绍了SAP系统中如何进行权限检查与控制,包括创建权限对象类、配置授权对象及在程序中实现权限检查的方法。通过具体示例,帮助读者理解如何确保用户拥有正确的权限来运行特定的事务代码或程序。

User Authority Check
---
About Authorty Common T-Code:

SU01:Assign profile=>就是创建用户然后分配权限的profile
SU02:Creating profile=>创建profile
SU03:Creating authorization=>创建权限
PFCG:Role Maintain=>角色的维护
SU21:List of object class=>在这里创建object class
SU22:List of transaction with check object=>把事务代码相关的check object找出来
SU24:Maintain assignment of authorization object of transaction=>根据事务代码找到相关的authority object.
SU25:我没有权限使用,就是复制系统标准的profile
SUIM:Display a generated authorization profile
SU53:Display authorization data for user=>列出用户的权限
SM59:Display and Maintain RFC Destinations => 远程登录

---
Authority Check Type List:
    (1). Transcation Run Check.
   Create T-Code, you can in [Authorization Object] Field there Input Authority Object and Set Value Field.If User

want run the corresponding T-Code, User must have the corresponding authority,else user run the T-Code ,system will show

message.
    (2). Program Run Check.
   In the ABAP Program Attributes,Input Authorization Groups Attribute, Authorization Group and S_Develop and

S_Program Authorization Object 's P_Group Field Correlation.Via Check the Field and User Master Record's Corresponding value

to decide user whether run this program.
    (3). Inside Program Authorization Check.
   If System Can not automatic control user run the program's Authorization, You may also use inside program check

authorization.
 Check Like this:
 Authority-Check Object 'Object_Name'
   ID   'Field_Name1'     Field  F1
   ID   'Field_Name2'     Field     F2

 If you not want check some field,you can set:
   ID   'Field_Name'      Dummy


Step 1: Use T-Code:SU21 Crate a Atuhority Object Class
     e.g:  ZZW01

Step 2: Use T-Code: PFCG  Or SU02->TO Profile Generator.
       
  Authorizations -> Change Authorization Data ->Manually(At Menu Bar) ->Authorization Object ->ZZW01

Step 3: Codeing.

---Complete Program: ZZW_AUTHORITY_CHECK

*-----------------------------------------------------------------------
*
*  Company ASAT Company Limited
*
*  ProgrameName:  ZZW_AUTHORITY_CHECK
*
*  Author: Wei_Zhu
*
*  Date: 06/01/2007
*
*  Description: Study SAP In Programe How To Check Control User
*               Authority.
*
*-----------------------------------------------------------------------
REPORT  ZZW_AUTHORITY_CHECK                     .
  Parameters: P_Carrid  Type Sflight-Carrid.

  Authority-Check  Object 'ZZW01'
           ID 'CARRID' Field P_CARRID
           ID 'ACTVT'  Field '999'.

if SY-SUBRC = 4.
  Message e045(sabapdocu) with p_carrid.
elseif sy-subrc <> 0.
*  message e045(sabapdocu) with 'Error!'.
  message e045(sabapdocu) with sy-subrc.
endif.

<think>我们正在处理一个关于Oracle权限故障检查的问题。用户提到“Oracle check authority fault”,结合之前的对话历史,用户可能是在进行权限相关的故障排查。 根据引用[1]的内容,用户似乎在使用SQLMonitor工具来监视对Oracle的访问,并遇到了错误(error 1060),但工具仍然可以捕获SQL语句。 然而,用户当前的问题是关于检查权限故障(check authority fault),这可能与权限授予、权限验证或权限监控相关。 由于引用内容中并没有直接提供关于权限检查的具体方法,我们需要结合Oracle的常见权限故障排查方法进行回答。 以下是针对Oracle权限故障的检查步骤: 1. **确认错误信息**: 当用户遇到权限问题时,通常会收到具体的错误代码,例如ORA-01031: insufficient privileges。记录错误代码是诊断的第一步。 2. **检查用户权限**: 使用以下SQL查询当前用户对特定对象的权限: ```sql -- 检查当前用户对某表的权限 SELECT * FROM user_tab_privs WHERE table_name = '表名大写'; -- 检查当前用户拥有的系统权限 SELECT * FROM user_sys_privs; -- 检查当前用户拥有的角色 SELECT * FROM user_role_privs; ``` 3. **检查角色权限**: 如果用户通过角色获得权限,需要确认角色是否被激活,并且角色所包含的权限是否正确。 ```sql -- 检查角色包含的权限 SELECT * FROM role_sys_privs WHERE role = '角色名'; SELECT * FROM role_tab_privs WHERE role = '角色名'; ``` 4. **检查间接权限(通过角色)**: 有时候用户通过角色获得了权限,但直接查询用户权限可能看不到,需要检查角色权限。另外,注意在存储过程中默认不使用角色权限(除非使用invoker rights或显式设置角色)。 5. **检查权限传递链**: 如果权限是通过多层角色授予的,需要检查整个角色链。 6. **使用数据字典视图综合检查**: Oracle提供了`DBA_TAB_PRIVS`(需要DBA权限)来查看所有用户的对象权限。 ```sql -- 以DBA身份检查某用户对某表的权限 SELECT * FROM dba_tab_privs WHERE grantee = '用户名' AND table_name = '表名大写'; ``` 7. **检查权限是否足够**: 例如,执行存储过程需要`EXECUTE`权限,执行DDL需要相应的系统权限(如`CREATE TABLE`)等。 8. **考虑权限的作用范围**: 例如,如果用户被授予了`SELECT ANY TABLE`,那么可以查询任何表,但这通常是一个系统权限,授予需谨慎。 9. **检查权限是否被回收**: 权限可能被回收导致失效,可以通过审计功能查看权限变更历史(如果开启了审计)。 10. **使用SQLMonitor或其他监控工具**: 如引用[1]中提到的SQLMonitor,可以捕获实际执行的SQL语句,从而帮助判断是哪个操作因为权限问题失败。 11. **检查是否在存储过程中遇到权限问题**: 在存储过程中,默认使用定义者权限(definer's rights),此时执行存储过程的用户需要被直接授予存储过程中涉及对象的权限(而不是通过角色)。可以尝试将存储过程改为调用者权限(invoker's rights)来避免此问题。 12. **检查系统权限**: 有些操作需要系统权限,例如创建表需要`CREATE TABLE`,创建视图需要`CREATE VIEW`等。 13. **检查对象是否存在**: 有时错误信息是权限不足,但实际上可能是对象不存在,因为Oracle为了避免暴露信息,对于不存在的对象也会报权限不足(出于安全考虑)。所以需要确认对象存在。 14. **检查同义词**: 如果通过同义词访问对象,需要确认同义词指向的对象是否存在,以及用户是否有访问该对象的权限。 15. **检查权限的授予者**: 权限必须由具有授予权限的用户(或角色)授予。例如,如果用户A将表T的SELECT权限授予用户B,那么用户A必须拥有该表且具有GRANT OPTION权限,或者拥有GRANT ANY OBJECT PRIVILEGE系统权限。 16. **检查权限的生效时间**: 权限授予后立即生效,但会话中的权限可能因为会话建立时角色未激活而不可用。可以使用`SET ROLE`命令激活角色。 17. **使用跟踪或调试工具**: 如果问题复杂,可以使用Oracle的跟踪功能(如SQL_TRACE)或调试工具来获取更详细的信息。 18. **查看审计日志**: 如果启用了审计,可以查看审计日志来了解权限相关的操作。 19. **考虑权限继承和代理用户**: 在复杂的权限模型中,代理用户和权限继承也可能导致问题。 20. **检查操作系统和网络权限**: 如果涉及外部表、目录对象等,还需要检查操作系统文件权限以及Oracle目录对象的读写权限。 由于引用[1]提到使用SQLMonitor时遇到错误,但可以捕获SQL语句,因此建议用户: - 捕获导致权限错误的SQL语句。 - 分析该SQL语句需要哪些权限。 - 检查执行该语句的用户是否具有这些权限(直接或通过角色)。 另外,引用[2]和引用[3]似乎与当前问题关联不大,引用[2]提到的是文件传输工具(SFTP/FTP)和Hadoop,引用[3]是dolphinscheduler的版本信息。 因此,我们主要参考引用[1]中关于使用监控工具的思路,并结合Oracle权限检查的常规方法。 如果用户没有提供具体的错误信息,我们可以建议一个通用的检查步骤: 步骤1:确认错误信息(如ORA错误号)。 步骤2:确认执行操作的用户。 步骤3:检查该用户是否具有执行操作所需的权限(系统权限和对象权限)。 步骤4:如果通过角色获得权限,检查角色是否在会话中激活。 步骤5:检查权限是否被回收。 步骤6:使用监控工具捕获实际执行的SQL,分析权限需求。 生成相关问题: 1. 如何解决Oracle中的ORA-01031权限不足错误? 2. 在Oracle中如何查看一个用户的所有权限? 3. Oracle中角色权限为什么在存储过程中不可用? 4. 如何监控Oracle中的权限变更? 5. 如何配置Oracle审计以跟踪权限操作? 注意:由于引用内容有限,我们的回答主要基于通用的Oracle权限故障排查知识。</think>### Oracle 权限故障检查指南 当出现权限故障时(如 ORA-01031: insufficient privileges),按以下步骤排查: --- #### **1. 确认当前用户权限** ```sql -- 检查当前用户系统权限 SELECT * FROM USER_SYS_PRIVS; -- 检查当前用户对象权限 SELECT * FROM USER_TAB_PRIVS_RECD; -- 表/视图权限 SELECT * FROM USER_ROLE_PRIVS; -- 角色权限 ``` --- #### **2. 验证目标对象权限** ```sql -- 检查特定表权限(需DBA权限) SELECT grantee, privilege FROM DBA_TAB_PRIVS WHERE table_name = 'EMPLOYEES' AND owner = 'TARGET_USER'; -- 引用[1][^1] ``` > ✅ 确认操作用户是否在 `grantee` 列表中 --- #### **3. 检查角色权限激活状态** ```sql -- 查看会话中激活的角色 SELECT * FROM SESSION_ROLES; -- 手动激活角色(如未激活) SET ROLE read_only_role; -- 角色名需大写 ``` > ⚠️ 存储过程中角色权限默认不生效,需使用 **显式授权** 或 **AUTHID CURRENT_USER**[^2] --- #### **4. 监控权限变更历史** ```sql -- 开启审计(需DBA权限) AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS; -- 查询权限变更记录 SELECT os_username, obj_name, action_name, timestamp FROM DBA_AUDIT_OBJECT WHERE owner = 'TARGET_USER' ORDER BY timestamp DESC; ``` > 💡 结合 SQL Monitor 工具捕获实时权限操作(引用[1][^1]) --- #### **5. 常见故障场景** | 故障现象 | 原因 | 解决方案 | |---------------------------|-------------------------------|------------------------------| | ORA-01031 | 直接权限缺失 | `GRANT SELECT ON table TO user` | | 存储过程权限失效 | 角色权限未继承 | 使用 `AUTHID CURRENT_USER` 子句 | | 同义词访问失败 | 基础表权限不足 | 直接授权基础表 | | 跨用户查询被拒 | 未授予对象权限 | `GRANT SELECT ON owner.table TO user` | --- #### **6. 权限诊断工具** 1. **SQL Monitor** - 捕获实时 SQL 操作及权限错误(引用[1][^1]) - 使用命令:`EXEC DBMS_SQL_MONITOR.REPORT_SQL_MONITOR(type=>'TEXT')` 2. **Oracle Audit Vault** - 集中管理权限变更审计日志 - 配置路径:`AV$ARCHIVED_LOG` 视图 --- ### 关键检查点总结 1. **直接权限 > 角色权限**:关键操作需直接授权 2. **存储过程权限**:显式声明 `AUTHID CURRENT_USER` 3. **同义词依赖**:确保基础对象有权限 4. **审计跟踪**:定期检查 `DBA_AUDIT_TRAIL` > 📌 **紧急恢复方案**: > ```sql > -- 临时授予完整权限(生产环境慎用) > GRANT SELECT ANY TABLE, INSERT ANY TABLE TO app_user; > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值