WL#12820: Extend GRANT syntax to cover partial revokes information
Affects: Server-8.0 — Status: Complete — Priority: Medium
WL#12098 introduced concept of partial revokes associated with global privileges grants. In an HA environment, grants and revoke require knowledge of grantor's context to be able to replicate the effect of the grant uniformly across different nodes. This is done by adding grantor's information in binary log's query log event header. Secondary nodes use this information to set required context and replay grant/revoke. However, for tools like mysqlbinlog, there is no way to set grantor's context because it uses a regular libmysqlclient connection. This impacts point in time recovery using mysqlbinlog because grants can not be replayed reliably. This worklog aims at introducing extensions to GRANT/REVOKE syntax such that partial revoke information is passed as a part of SQL itself. Feature will make sure that rewritten GRANT/REVOKE are not dependent on grantor's information and can be replayed uniformly on any node.
Definition ========== User: User executing GRANT statement. Grantor: Authorization ID that is a part of new syntax extension. Active_roles: Authorization IDs treated as active roles for Grantor - Also explicitly specified as a part of new syntax extension. Functional Requirements ======================= FR1: Server should support an extension to GRANT syntax to specify information about grantor and active roles information. New extension: [AS user [WITH ROLE DEFAULT | NONE | ALL | ALL EXCEPT role [, role ] ...] | role [, role ] ...] ] Complete GRANT syntax should look like following: GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ... ON [object_type] priv_level TO user_or_role [, user_or_role] ... [WITH GRANT OPTION] [AS user [WITH ROLE DEFAULT | NONE | ALL | ALL EXCEPT role [, role ] ...] | role [, role ] ...] ] Purpose of the new syntax extension is to make sure that restrictions associated with Grantor (and Active_roles) are applied to grantee even if statement is executed by User - who may have superior set of privileges. FR2: In order to specify new extension, following privilege restrictions apply: 1. User must have ability to grant all privileges mentioned in GRANT statement 2. If --partial_revoke is set to ON and if User has restrictions associated with privileges being granted through GRANT statement, Grantor along with all Active_roles set, must also have same or more restrictions. FR3: The new extension should work only for global privilege grants i.e. if priv_level is *.*. FR3.1: Exception to FR3 is GRANT PROXY. New extension will not be supported for proxy grants. FR4: Effect on query logging: 1. If --partial_revokes is set to ON, while rewriting GRANT to binary log, information about Grantor and Active_roles should be added to binary log. 2. GRANT must not be rewritten for any other logs e.g. general log, audit log etc. FR5: Impact on replication: 1. Please see point 1 of FR4 for impact on binary log. 2. Changes introduced to binary log query event header by WL#12098 must be reverted because they are no longer needed. FR6: Incompatibility warnings introduced by while setting --partial_revokes should be removed as they are no longer required. These were introduced by WL#12098.
HLS1: GRANT will support new clause as mentioned in FR1. LEX will be updated to contain information about new clause in GRANT statement. Parser will be changed to support new clause for: GRANT ... TO ... GRANT ALL ON *.* TO ... A special case of GRANT ... AS ... is when user executing the GRANT statement is same as user in AS clause - either by specifying user name explicitly or using CURRENT_USER(). A usecase for such usage is - a user who has activated many roles wants to make sure that only a subset of roles play part while granting privileges to grantee. This may be required in order to pass a stricter set of permission through e.g. restriction list. HLS2: Rationale for FR2. The main use-case for the syntax extension is to make sure that information related to restrictions is available in binary log in SQL format so that mysqlbinlog can extract and execute it. The fundamental assumption here is: PITR through mysqlbinlog would typically use a user account that has privileges higher than regular users to make sure that ALL statements in binary logs are replayed without any problem. In case of PITR with --partial-revokes=ON, GRANT can cause a user to have more privileges than the actual grant executed by regular user with restriction list. This is because restrictions are are passed from grantor to grantee. If we do not check for privileges mentioned in point 1 and 2 of FR2, user may be able perform privilege escalation through new statement because while intended use is for mysqlbinlog, it still is a valid SQL that can be explicitly executed. Hence, User executing GRANT must have superior privilege set then user/role combination specified in AS ... part. Note that, only privileges being granted through the statement are of interest at this point. We do not care of about difference wrt other privileges because they do not play any role in given GRANT statement. HLS3: Rationale for FR5 WL#12098 introduced new flag - ACTIVE_ROLES for query event header of binary log. As per FR4, new extension will be used to capture invoker's context while rewriting query for binary log. Hence, there is no need to pass same information again through ACTIVE_ROLES and subsequently use it on slave side. Since both: WL#12098 and WL#12820 are meant for same MRU, we can safely revert these changes without any customer visible impact. HLS4: If --partial_revokes is set to ON, when GRANT is rewritten to binary log, it will always contain complete list of roles. We will not use keywords like NONE/DEFAULT/ALL. If user has explicitly specified GRANT ... AS ... query using NONE/DEFAULT/ALL, it will be logged as it is. HLS5: Impact on replication - In case of OLD->NEW setup, behavior should be compatible. - In case of NEW->OLD setup, behavior is incompatible if extension proposed in FR1 is used. HLS6: No impact on UPGRADE
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.