오라클 함수 생성/컴파일 시 권한 에러 조치

오라클 함수 실행시 권한 에러 조치

다른유저 함수를 실행하는 권한을 롤(ROLE)에 부여하여하고 자신 함수에서 호출 하는 경우

menu_book Oracle 데이터베이스에서 PL/SQL 함수, 프로시저 등을 생성할 때 발생하는 권한 문제는 매우 흔하며,

• 주로 롤(Role)을 통한 권한 상속 방식
• 직접 부여된 권한의 차이 때문에 발생합니다.

menu_book 질문 1) 유저A는 유저B.F1함수를 실행할수 있는 권한을 롤로 부여 받았다.

2) 유저A는 F2함수를 생성하고 F2함수는 내부에서 유저B.F1함수를 호출한다.

3) 왜 유저A가 함수 F2을 생성 하려고 하는데 유저B.F1함수 실행 권한이 없다는 에러가 발생하는가?

• 답변) Oracle에서는 PL/SQL 프로시저(함수, 프로시저, 패키지)를 컴파일(CREATE FUNCTION/PROCEDURE)할 때는 롤을 통해 부여된 권한을 인식하지 못합니다.

• **컴파일 시점 (Definition Rights)**: 함수 A를 생성(컴파일)하는 시점에는, 해당 함수를 생성하는 사용자에게 B함수에 대한 `EXECUTE` 권한이 **직접(Directly)** 부여되어 있어야 합니다. 롤(C롤)을 통해 부여된 권한은 컴파일 시점의 권한 체크에서는 유효하게 인식되지 않습니다. 이는 PL/SQL 객체의 보안과 안정성을 높이기 위한 Oracle의 설계 원칙입니다. 즉, PL/SQL 코드를 작성하고 컴파일하는 사용자는 해당 코드에 참조되는 모든 객체에 대한 명시적인 권한을 가지고 있어야 합니다.
• **실행 시점 (Invoker's Rights / Definer's Rights)**:

   * **Definer's Rights (기본값)**: A함수가 생성될 때 `AUTHID DEFINER` (기본값)로 생성되면, A함수가 실행될 때 A함수를 생성한 사용자의 권한으로 B함수를 호출합니다. 이 경우에도 B함수에 대한 권한은 A함수를 생성한 사용자에게 **직접** 부여되어 있어야 합니다.
   * **Invoker's Rights (AUTHID CURRENT_USER)**: 만약 A함수가 `AUTHID CURRENT_USER`로 생성되었다면, A함수가 실행될 때 A함수를 실행하는 사용자의 권한으로 B함수를 호출합니다. 이때는 A함수를 실행하는 사용자 또는 해당 사용자가 가진 롤에 B함수 `EXECUTE` 권한이 있어야 B함수를 호출할 수 있습니다. 하지만 **함수를 생성하는 시점의 권한 문제**와는 별개입니다.

결론적으로, A함수를 생성(컴파일)할 때는 **C롤을 통해 B함수 `EXECUTE` 권한이 부여되어 있더라도, Oracle은 이를 유효한 권한으로 간주하지 않습니다.**

1. 1. 1. 질문 2: 사용자에게 직접 B함수 실행 권한을 부여하면 권한 에러가 발생되지 않는가?

• • 네, 맞습니다.** 사용자에게 B함수에 대한 `EXECUTE` 권한을 직접 부여하면 A함수 생성 시 발생하는 권한 에러는 해결될 것입니다.

예를 들어, A함수를 생성하려는 사용자(예: `USER_A`)가 있다고 가정하고, B함수가 `SCHEMA_B` 스키마에 있다고 가정할 때:

```sql -- USER_A 에게 SCHEMA_B.B 함수에 대한 실행 권한을 직접 부여 GRANT EXECUTE ON SCHEMA_B.B TO USER_A; ```

이렇게 직접 권한을 부여한 후 `USER_A`로 로그인하여 A함수를 생성하면, A함수는 B함수를 성공적으로 참조하고 컴파일될 것입니다.

• • 왜 직접 권한이 필요한가?**

Oracle은 PL/SQL 객체의 의존성과 안정성을 중요하게 생각합니다. 롤을 통해 부여된 권한은 동적으로 변할 수 있습니다 (롤이 부여되거나 회수될 수 있음). 만약 롤에 의해 부여된 권한으로 함수를 컴파일할 수 있다면, 나중에 해당 롤이 변경되어 함수가 참조하는 객체에 대한 권한이 사라졌을 때 함수가 무효화되거나 런타임 오류를 일으킬 수 있습니다.

따라서 Oracle은 PL/SQL 객체가 생성될 때는 해당 객체가 의존하는 모든 객체에 대한 권한이 **영구적으로 보장될 수 있는 직접 부여된 권한**이 있어야 한다고 강제합니다.

1. 1. 1. 추가 고려사항:

• **B함수에서 조회하는 테이블 권한**: A함수를 생성할 때 B함수를 호출하는 데에는 B함수 `EXECUTE` 권한만 필요합니다. B함수 내부에서 어떤 테이블을 조회하든 그 테이블에 대한 `SELECT` 권한은 B함수의 `DEFINER` (B함수를 생성한 사용자)가 가지고 있어야 합니다. 즉, B함수를 생성할 때 이미 B함수가 참조하는 테이블에 대한 권한이 B함수 생성자에게 직접 부여되어 있어야 합니다. 이는 A함수 생성과는 직접적인 관련이 없습니다.
• **권한 관리의 복잡성**: 프로덕션 환경에서는 모든 사용자에게 직접 권한을 부여하는 것이 관리상 비효율적일 수 있습니다. 이러한 경우, PL/SQL 개발을 위한 특정 스키마/사용자를 만들고, 해당 스키마/사용자에게 필요한 모든 객체에 대한 직접 권한을 부여하는 방식을 사용하기도 합니다. 그리고 일반 사용자들에게는 이러한 프로시저를 실행할 수 있는 권한을 롤을 통해 부여하는 방식으로 관리합니다.