Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.13 When Privilege Changes Take Effect의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
mysqld 서버가 --skip-grant-tables 옵션 없이 시작되면, 시작 시퀀스 동안 모든 권한 테이블 내용을 메모리로 읽어들입니다. 이 메모리에 상주하는 테이블들은 그 시점부터 액세스 제어에 대해 유효해집니다.
계정 관리 문을 사용하여 권한 테이블을 간접적으로 수정하면, 서버는 이러한 변경 사항을 감지하고 권한 테이블을 즉시 다시 메모리로 로드합니다. 계정 관리 문에 대해서는 Section 15.7.1, “Account Management Statements”을 참고하십시오. 예로는 GRANT,
REVOKE, SET PASSWORD, RENAME USER 등이 있습니다.
INSERT,
UPDATE,
DELETE (권장되지 않음)와 같은 문을 사용하여 권한 테이블을 직접 수정하는 경우, 서버에 테이블을 다시 로드하도록 지시하거나 서버를 다시 시작할 때까지 해당 변경 사항은 권한 검사에 아무런 영향을 미치지 않습니다. 따라서 권한 테이블을 직접 변경했지만 이를 다시 로드하는 것을 잊으면, 서버를 다시 시작할 때까지 변경 사항은 아무 효과도 없습니다. 이 때문에 왜 변경이 아무 차이도 만들지 않는 것처럼 보이는지 의아해할 수 있습니다!
서버에 권한 테이블을 다시 로드하라고 지시하려면 권한 플러시 작업을 수행하십시오. 이는 FLUSH PRIVILEGES 문을 실행하거나, mysqladmin flush-privileges 또는 mysqladmin reload 명령을 실행하여 수행할 수 있습니다.
권한 테이블을 다시 로드하는 것은 각 기존 클라이언트 세션의 권한에 대해 다음과 같이 영향을 미칩니다:
테이블 및 열 권한 변경 사항은 클라이언트의 다음 요청 시점에 적용됩니다.
데이터베이스 권한 변경 사항은 클라이언트가 다음에 USE db_name 문을 실행할 때 적용됩니다.
참고
클라이언트 애플리케이션은 데이터베이스 이름을 캐시할 수 있습니다. 따라서 실제로 다른 데이터베이스로 변경하지 않으면 이 효과가 보이지 않을 수 있습니다.
세션 내 활성 역할 집합에 대한 변경 사항은 해당 세션에 대해서만 즉시 적용됩니다. SET ROLE 문은 세션 역할의 활성화 및 비활성화를 수행합니다(참고: Section 15.7.1.11, “SET ROLE Statement”).
서버가 --skip-grant-tables 옵션과 함께 시작되면, 권한 테이블을 읽지 않으며 어떠한 액세스 제어도 구현하지 않습니다. 어떤 사용자든지 연결해서 아무 작업이나 수행할 수 있는데, 이는 매우 위험합니다. 이렇게 시작된 서버가 테이블을 읽고 액세스 검사를 활성화하도록 하려면, 권한을 플러시하십시오.
8.2.12 Privilege Restriction Using Partial Revokes
8.2.14 Assigning Account Passwords