데브러너 (DevRunner)

8.2.7 Access Control, Stage 2: Request Verification

서버가 connection을 허용한 후에는 access control의 Stage 2에 들어갑니다. connection을 통해 전송되는 각 request에 대해, 서버는 사용자가 수행하려는 operation이 무엇인지 결정한 다음, 사용자의 권한이 충분한지 확인합니다. 이때 grant table의 권한 column이 사용됩니다. 이러한 권한은 user, global_grants, db, tables_priv, columns_priv, 또는 procs_priv table 중 어느 것이든에서 제공될 수 있습니다. (각 grant table에 존재하는 column 목록은 Section 8.2.3, “Grant Tables”을 참조하면 도움이 될 것입니다.)

user 및 global_grants table은 글로벌 권한을 부여합니다. 특정 account에 대한 이들 table의 row는 기본 database가 무엇이든 상관없이 글로벌하게 적용되는 account 권한을 나타냅니다. 예를 들어, user table이 사용자에게 DELETE 권한을 부여하면, 서버 host의 어떤 database에 있는 어떤 table에서든 row를 삭제할 수 있습니다. user table에서는 데이터베이스 관리자와 같이 정말 필요한 사람에게만 권한을 부여하는 것이 좋습니다. 다른 사용자에 대해서는 user table의 모든 권한을 'N'으로 두고, 보다 구체적인 수준(특정 database, table, column 또는 routine)에 대해서만 권한을 부여하십시오. 또한 database 권한을 글로벌하게 부여하되 partial revoke를 사용하여 특정 database에서 권한이 사용되지 못하도록 제한할 수도 있습니다(참고: Section 8.2.12, “Privilege Restriction Using Partial Revokes”).

db table은 database-specific 권한을 부여합니다. 이 table의 scope column 값은 다음과 같은 형태를 취할 수 있습니다:

비어 있는 User 값은 anonymous user와 일치합니다. 비어 있지 않은 값은 그대로 literal로 매칭되며, user name에는 와일드카드가 없습니다.
와일드카드 문자 % 및 _는 Host 및 Db column에서 사용할 수 있습니다. 이는 LIKE 연산자로 수행되는 패턴 매칭 연산에서와 동일한 의미를 가집니다. 권한을 부여할 때 이러한 문자를 literal로 사용하려면 백슬래시로 이스케이프해야 합니다. 예를 들어, database 이름의 일부로 언더스코어 문자(_)를 포함하려면 GRANT statement에서 \_로 지정해야 합니다.
'%' 또는 비어 있는 Host 값은 “any host”를 의미합니다.
'%' 또는 비어 있는 Db 값은 “any database”를 의미합니다.

서버는 user table을 읽을 때와 동시에 db table을 메모리로 읽어 들이고 정렬합니다. 서버는 Host, Db, User scope column을 기준으로 db table을 정렬합니다. user table의 경우와 마찬가지로, 정렬 시 가장 구체적인 값이 먼저, 가장 덜 구체적인 값이 나중에 오도록 배치되며, 서버가 일치하는 row를 찾을 때는 처음 발견한 매칭 row를 사용합니다.

tables_priv, columns_priv, procs_priv table은 각각 table-specific, column-specific, routine-specific 권한을 부여합니다. 이들 table의 scope column 값은 다음과 같은 형태를 취할 수 있습니다:

와일드카드 문자 % 및 _는 Host column에서 사용할 수 있습니다. 이는 LIKE 연산자로 수행되는 패턴 매칭 연산에서와 동일한 의미를 가집니다.
'%' 또는 비어 있는 Host 값은 “any host”를 의미합니다.
Db, Table_name, Column_name, Routine_name column에는 와일드카드를 사용할 수 없으며 비워 둘 수도 없습니다.

서버는 tables_priv, columns_priv, procs_priv table을 Host, Db, User column을 기준으로 정렬합니다. 이는 db table 정렬과 유사하지만, 와일드카드를 포함할 수 있는 column이 Host 하나뿐이므로 더 단순합니다.

서버는 정렬된 table을 사용하여 수신하는 각 request를 검증합니다. SHUTDOWN 또는 RELOAD과 같은 administrative 권한이 필요한 request의 경우, 서버는 administrative 권한을 지정하는 table이 user와 global_privilege table뿐이므로 이 두 table만 확인합니다. 이들 table에 있는 account row가 요청된 operation을 허용하면 서버는 access를 허가하고, 그렇지 않으면 access를 거부합니다. 예를 들어, mysqladmin shutdown을 실행하고자 하지만 user table row가 사용자에게 SHUTDOWN 권한을 부여하지 않은 경우, 서버는 db table을 확인해 보지도 않고 access를 거부합니다. (db table에는 Shutdown_priv column이 없으므로 확인할 필요가 없습니다.)

INSERT, UPDATE 등 database와 관련된 request의 경우, 서버는 먼저 user table row에서 사용자의 글로벌 권한(및 partial revoke에 의해 부과된 권한 제한을 제외한 나머지 권한)을 확인합니다. 해당 row가 요청된 operation을 허용하면 access가 허가됩니다. user table의 글로벌 권한이 충분하지 않은 경우, 서버는 db table에서 사용자의 database-specific 권한을 결정합니다:

서버는 db table에서 Host, Db, User column이 일치하는 row를 찾습니다.
Host 및 User column은 접속 중인 사용자의 host name과 MySQL user name에 매칭됩니다.
Db column은 사용자가 access하려는 database에 매칭됩니다.
해당 Host와 User에 대한 row가 없으면 access가 거부됩니다.

서버가 db table row로부터 부여된 database-specific 권한을 결정한 후, user table이 부여한 글로벌 권한에 이를 더합니다. 그 결과가 요청된 operation을 허용하면 access가 허가됩니다. 그렇지 않으면 서버는 차례로 tables_priv 및 columns_priv table에서 사용자의 table 및 column 권한을 확인하고, 이를 사용자의 권한에 더한 후 그 결과에 따라 access를 허가하거나 거부합니다. 저장 프로시저 및 함수와 같은 stored routine operation의 경우, 서버는 tables_priv 및 columns_priv 대신 procs_priv table을 사용합니다.

boolean 관점에서 보면, 사용자의 권한이 계산되는 방식은 다음과 같이 요약할 수 있습니다:

1global privileges
2OR database privileges
3OR table privileges
4OR column privileges
5OR routine privileges

요청된 operation에 대해 처음 글로벌 권한이 충분하지 않은 것으로 판정되었는데도, 서버가 나중에 이 권한을 database, table, column 권한에 더하는 이유는 분명해 보이지 않을 수 있습니다. 그 이유는 하나의 request에 둘 이상의 권한이 필요할 수 있기 때문입니다. 예를 들어, INSERT INTO ... SELECT statement를 실행하면 INSERT 권한과 SELECT 권한이 모두 필요합니다. 사용자의 권한 구성이 user table row에서 한 권한을 글로벌하게 부여하고, db table row에서 다른 권한을 해당 database에 대해 구체적으로 부여하는 형태일 수도 있습니다. 이 경우 사용자는 해당 request를 수행하는 데 필요한 권한을 모두 가지고 있지만, 서버는 글로벌 권한만 보거나 database 권한만 봐서는 이를 알 수 없습니다. 서버는 결합된 권한을 기반으로 access-control 결정을 내려야 합니다.