Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
Roles
As (or close to) defined in the SQL:2003 standard.
New statements
CREATE ROLE role
|
DROP ROLE role
|
GRANT role TO { user | user }
|
REVOKE role FROM {user | role }
|
SET ROLE { role_name | NONE }
|
According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory @host part (even if it's @%). And we probably wouldn't want it for roles. So, practically, we will have users and roles in different name spaces, with a little ambiguity, when a user name is specified without a @host part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way.
Only one role can be set to a user at any specific point in any given session. In other words, CURRENT_ROLE (see below) can never return a list.
Privileges
One needs CREATE USER privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the mysql database.
One needs a role to be granted to himself WITH ADMIN OPTION to be able to grant or revoke it further. A creator of a role gets it automatically granted to himself WITH ADMIN CURRENT_USER. Alternatively, one can use WITH ADMIN CURRENT_ROLE or (with SUPER privilege) WITH ADMIN arbitrary_definer.
Existing statements need to work with roles
REVOKE privilege FROM { user | role }
|
GRANT privilege TO { user | role }
|
SHOW GRANTS FOR { user | role }
|
New functions
CURRENT_ROLE
|
CURRENT_ROLE()
|
If there is no current role, the function returns NULL, not "NONE".
Informational tables
INFORMATION_SCHEMA.APPLICABLE_ROLES
|
INFORMATION_SCHEMA.ENABLED_ROLES
|
there are more tables in the INFORMATION_SCHEMA that are relevant for roles. They are not part of this task.
DEFINER=CURRENT_ROLE
Everywhere where one can write DEFINER=xxx, we should allow xxx to be a role name. And additionally we'll support DEFINER=CURRENT_ROLE.
Reserved role names
The role name of PUBLIC is reserved. There can be no role with this name. But this name can be used in GRANT and REVOKE statements as a grantee.Privileges granted to PUBLIC are always available to everyone. Implementing it is not part of this task.
The role name of NONE is reserved too.
Default role (not part of this task)
Syntax variants (which ones we'll do?):
CREATE USER xxx DEFAULT ROLE yyy;
|
ALTER USER xxx DEFAULT ROLE yyy;
|
SET DEFAULT ROLE yyy;
|
SET DEFAULT ROLE yyy [ FOR xxx ];
|
When a default role is set, the server implicitly runs SET ROLE yyy for every new connection (or after a COM_CHANGE_USER for a user xxx.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- causes
-
MDEV-24345 WITH ADMIN OPTION privilege is missing from SHOW PRIVILEGES
-
- Closed
-
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Open
-
(19 relates to)
Activity
| Field | Original Value | New Value |
|---|---|---|
| Labels | gsoc13 |
| Fix Version/s | 10.0.5 [ 13201 ] |
| Assignee | Sergey Vojtovich [ svoj ] |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE [ IF NOT EXISTS ] role DROP ROLE [ IF EXISTS ] role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. Alternatively, we may want to introduce {{CREATE ROLE}} privilege. One needs a role to be granted to himself to be able to grant or revoke it futher (assuming one has {{GRANT OPTION}}) or to set it. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. Alternatively, we may want to introduce {{CREATE ROLE}} privilege. One needs a role to be granted to himself to be able to grant or revoke it futher (assuming one has {{GRANT OPTION}}) or to set it. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. Alternatively, we may want to introduce {{CREATE ROLE}} privilege. One needs a role to be granted to himself to be able to grant or revoke it futher (assuming one has {{GRANT OPTION}}) or to set it. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN OPTION}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN OPTION}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN OPTION}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN OPTION}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
| Assignee | Sergey Vojtovich [ svoj ] | Sergei Golubchik [ serg ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. Definer Where we support {{DEFINER=CURRENT_USER}} we should also support {{DEFINER=CURRENT_ROLE}}. h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself to be able to grant or revoke it further. {panel:title=Question|titleBGColor=#F7D6C1|bgColor=#FFFFCE} Will we require traditional {{GRANT OPTION}} privilege to grant roles, or we'll go with the standard {{WITH ADMIN}} (which is an _option_ not a privilege)? {panel} h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself {{WITH ADMIN OPTION}} to be able to grant or revoke it further. A creator or a role gets it automatically granted to himself {{WITH ADMIN CURRENT_USER}}. Alternatively, one can use {{WITH ADMIN CURRENT_ROLE}} or (with {{SUPER}} privilege) {{WITH ADMIN arbitrary_definer}}. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself {{WITH ADMIN OPTION}} to be able to grant or revoke it further. A creator or a role gets it automatically granted to himself {{WITH ADMIN CURRENT_USER}}. Alternatively, one can use {{WITH ADMIN CURRENT_ROLE}} or (with {{SUPER}} privilege) {{WITH ADMIN arbitrary_definer}}. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself {{WITH ADMIN OPTION}} to be able to grant or revoke it further. A creator of a role gets it automatically granted to himself {{WITH ADMIN CURRENT_USER}}. Alternatively, one can use {{WITH ADMIN CURRENT_ROLE}} or (with {{SUPER}} privilege) {{WITH ADMIN arbitrary_definer}}. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
| Description |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself {{WITH ADMIN OPTION}} to be able to grant or revoke it further. A creator of a role gets it automatically granted to himself {{WITH ADMIN CURRENT_USER}}. Alternatively, one can use {{WITH ADMIN CURRENT_ROLE}} or (with {{SUPER}} privilege) {{WITH ADMIN arbitrary_definer}}. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informatinal tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. May be we won't implement it, though. The role name of {{NONE}} is reserved too. h3. Default role (optional) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. |
h2.Roles As (or close to) defined in the SQL:2003 standard. h3. New statements {noformat} CREATE ROLE role DROP ROLE role GRANT role TO { user | user } REVOKE role FROM {user | role } SET ROLE { role_name | NONE } {noformat} According to the standard, role and user names live in the same namespace. But in MariaDB a user name has a mandatory {{@host}} part (even if it's {{@%}}). And we probably wouldn't want it for roles. So, practically, we will have users and roles in _different_ name spaces, with a little ambiguity, when a user name is specified without a {{@host}} part, where allowed. Alternatively, we can specify that a role name cannot match the first part of any user name. May be it'll be less confusing this way. Only one role can be set to a user at any specific point in any given session. In other words, {{CURRENT_ROLE}} (see below) can never return a list. h3. Privileges One needs {{CREATE USER}} privilege to create or drop a role. Or an appropriate (insert or delete) privilege on the {{mysql}} database. One needs a role to be granted to himself {{WITH ADMIN OPTION}} to be able to grant or revoke it further. A creator of a role gets it automatically granted to himself {{WITH ADMIN CURRENT_USER}}. Alternatively, one can use {{WITH ADMIN CURRENT_ROLE}} or (with {{SUPER}} privilege) {{WITH ADMIN arbitrary_definer}}. h3. Existing statements need to work with roles {noformat} REVOKE privilege FROM { user | role } GRANT privilege TO { user | role } SHOW GRANTS FOR { user | role } {noformat} h3. New functions {noformat} CURRENT_ROLE CURRENT_ROLE() {noformat} If there is no current role, the function returns {{NULL}}, not {{"NONE"}}. h3. Informational tables {noformat} INFORMATION_SCHEMA.APPLICABLE_ROLES INFORMATION_SCHEMA.ENABLED_ROLES {noformat} there are more tables in the {{INFORMATION_SCHEMA}} that are relevant for roles. They are not part of this task. h3. DEFINER=CURRENT_ROLE Everywhere where one can write {{DEFINER=xxx}}, we should allow {{xxx}} to be a role name. And additionally we'll support {{DEFINER=CURRENT_ROLE}}. h3. Reserved role names The role name of {{PUBLIC}} is reserved. There can be no role with this name. But this name can be used in {{GRANT}} and {{REVOKE}} statements as a grantee.Privileges granted to {{PUBLIC}} are always available to everyone. Implementing it is not part of this task. The role name of {{NONE}} is reserved too. h3. Default role (not part of this task) Syntax variants (which ones we'll do?): {noformat} CREATE USER xxx DEFAULT ROLE yyy; ALTER USER xxx DEFAULT ROLE yyy; SET DEFAULT ROLE yyy; SET DEFAULT ROLE yyy [ FOR xxx ]; {noformat} When a default role is set, the server implicitly runs {{SET ROLE yyy}} for every new connection (or after a {{COM_CHANGE_USER}} for a user {{xxx}}. |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Workflow | defaullt [ 27002 ] | MariaDB v2 [ 44504 ] |
| Workflow | MariaDB v2 [ 44504 ] | MariaDB v3 [ 66022 ] |
| Link |
This issue duplicates |
| Link |
This issue causes |
| Workflow | MariaDB v3 [ 66022 ] | MariaDB v4 [ 132102 ] |
Implemented something like this long ago in the Google patch. Will be great to see an officially supported version of it – https://code.google.com/p/google-mysql-tools/wiki/MysqlRoles