{"id":3667,"date":"2011-06-22T08:39:01","date_gmt":"2011-06-22T06:39:01","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=3667"},"modified":"2011-06-22T08:39:01","modified_gmt":"2011-06-22T06:39:01","slug":"mysql-security-inconsistencies","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/mysql-security-inconsistencies","title":{"rendered":"MySQL security: inconsistencies"},"content":{"rendered":"

Doing some work with MySQL security, I’ve noticed a few inconsistencies. They’re mostly not-too-terrible for daily work, except they get in my way right now.<\/p>\n

The ALL PRIVILEGES inconsistency<\/h4>\n

The preferred way of assigning account privileges in MySQL is by way of using GRANT<\/a>.<\/p>\n

With GRANT<\/strong>, one assigns one or more privileges to an account, such as SELECT<\/strong>, UPDATE<\/strong>, ALTER<\/strong>, SUPER<\/strong> ,etc. Sometimes it makes sense for an account to have complete control over a domain. For example, the root<\/strong> account is typically assigned with all privileges. Or, some user may require all possible privileges on a certain schema.<\/p>\n

Instead of listing the entire set of privileges, the ALL PRIVILEGES<\/strong> meta-privilege can be used. There is a fine issue to notice here; typically this is not a problem, but I see it as a flaw. Assume the following account:<\/p>\n

\n
root@mysql-5.1.51> GRANT ALL PRIVILEGES<\/strong> ON world.* TO 'world_user'@'localhost';\r\n\r\nroot@mysql-5.1.51> SHOW GRANTS FOR 'world_user'@'localhost';\r\n+---------------------------------------------------------------+\r\n| Grants for world_user@localhost\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+---------------------------------------------------------------+\r\n| GRANT USAGE ON *.* TO 'world_user'@'localhost'\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n| GRANT ALL PRIVILEGES<\/strong> ON `world`.* TO 'world_user'@'localhost' |\r\n+---------------------------------------------------------------<\/pre>\n<\/blockquote>\n
This makes sense. We granted ALL PRIVILEGES<\/strong> and we see that the account is granted with ALL PRIVILEGES<\/strong>.<\/p>\n
Now notice the following:<\/p>\n
\n
root@mysql-5.1.51> GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, EXECUTE, INDEX, INSERT, LOCK TABLES, REFERENCES, SELECT, SHOW VIEW, TRIGGER, UPDATE ON `world`.* TO 'other_user'@'localhost';\r\n\r\nroot@mysql-5.1.51> SHOW GRANTS FOR 'other_user'@'localhost';\r\n+---------------------------------------------------------------+\r\n| Grants for other_user@localhost\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+---------------------------------------------------------------+\r\n| GRANT USAGE ON *.* TO 'other_user'@'localhost'\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n| GRANT ALL PRIVILEGES<\/strong> ON `world`.* TO 'other_user'@'localhost' |\r\n+---------------------------------------------------------------+<\/pre>\n<\/blockquote>\n
I didn’t ask<\/em> for ALL PRIVILEGES<\/strong>. I explicitly listed what I thought should be an account’s privileges. It just so happens that these make for the entire set of privileges available on the schema domain.<\/p>\n
You might think this is a nice feature, an ease out MySQL provides with. I do not see it this way.<\/p>\n
My preferred way of upgrading MySQL version involves exporting and importing of the GRANTs. That is, I do not dump and load the mysql<\/strong> system tables, but rather export all the SHOW GRANTS FOR …<\/strong> (e.g. with mk-show-grants), then execute these on the new version. This process was extremely useful on upgrades from 5.0<\/strong> to 5.1<\/strong>, where some mysql<\/strong> system tables were modified.<\/p>\n
Now, consider the case where some new MySQL version introduced a new set of privileges. My ‘other_user’@’localhost’<\/strong> was not created with that set of privileges, nor did I intend it to have them. However, when exporting with SHOW GRANTS<\/strong>, the account is said to have ALL PRIVILEGES<\/strong>. When executed on the new version, the account will have privileges which I never assigned it<\/em>.<\/p>\n
Typically, this is not an issue. I mean, how many times do I assign an account with the entire set of privileges, yet do not intend it to have all privileges? Nevertheless, this makes for an inconsistency. It is unclear, by way of definition, which privileges are assigned to a user, without knowing the context of the version and the set of privileges per version. It makes for an inconsistency when moving between versions. And right now I’m working on some code which doesn’t like these inconsistencies.<\/p>\n
The WITH GRANT OPTION inconsistency<\/h4>\n
An account can be granted with the WITH GRANT OPTION<\/strong> privilege, which means the account’s user can assign her privileges to other accounts. The inconsistency I found is that the GRANT<\/strong> mechanism is fuzzy with regard to GRANT OPTION<\/strong>, and falsely presents us with the wrong impression.<\/p>\n
Let’s begin with the bottom line: the WITH GRANT OPTION<\/strong> can only be set globally for an account-domain combination. Consider:<\/p>\n
\n
root@mysql-5.1.51> GRANT INSERT, DELETE, UPDATE ON world.City TO 'gromit'@'localhost';\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nroot@mysql-5.1.51> GRANT SELECT ON world.City TO 'gromit'@'localhost' WITH GRANT OPTION;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nroot@mysql-5.1.51> SHOW GRANTS FOR 'gromit'@'localhost';\r\n+--------------------------------------------------------------------------------------------------+\r\n| Grants for gromit@localhost\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+--------------------------------------------------------------------------------------------------+\r\n| GRANT USAGE ON *.* TO 'gromit'@'localhost'\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n| GRANT SELECT, INSERT, UPDATE, DELETE<\/strong> ON `world`.`City` TO 'gromit'@'localhost' WITH GRANT OPTION<\/strong> |\r\n+--------------------------------------------------------------------------------------------------+\r\n<\/pre>\n<\/blockquote>\n
The syntax of first two queries leads us to believe that we’re only providing the WITH GRANT OPTION<\/strong> for the SELECT<\/strong> privilege. But that is not so: the WITH GRANT OPTION<\/strong> is assigned for all privileges on world.City<\/strong> to ‘gromit’@’localhost’<\/strong>.<\/p>\n
The syntax would be more correct if we were to write something like:<\/p>\n
\n
GRANT GRANT_OPTION<\/strong> ON world.* TO 'gromit'@'localhost';<\/pre>\n<\/blockquote>\n
That would make it clear that this privilege does not depend on other privileges set on the specified domain.<\/p>\n
The USAGE inconsistency<\/h4>\n
You can GRANT<\/strong> the USAGE<\/strong> privilege, but you may never REVOKE<\/strong> it. To revoke USAGE<\/strong> means to DROP USER<\/strong>.<\/p>\n
The missing ROUTINES_PRIVILEGES inconsistency<\/h4>\n
INFORMATION_SCHEMA<\/strong> provides with four privileges tables: USER_PRIVILEGES<\/strong>, SCHEMA_PRIVILEGES<\/strong>, TABLE_PRIVILEGES<\/strong>, COLUMN_PRIVILEGES<\/strong>, which map well to mysql<\/strong>‘s user<\/strong>, db<\/strong>, tables_priv<\/strong> and columns_priv<\/strong> tables, respectively.<\/p>\n
Ahem, which INFORMATION_SCHEMA<\/strong> table maps to mysql.procs_priv<\/strong>?<\/p>\n","protected":false},"excerpt":{"rendered":"
Doing some work with MySQL security, I’ve noticed a few inconsistencies. They’re mostly not-too-terrible for daily work, except they get in my way right now. The ALL PRIVILEGES inconsistency The preferred way of assigning account privileges in MySQL is by way of using GRANT. With GRANT, one assigns one or more privileges to an account, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[24,16],"class_list":["post-3667","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-information_schema","tag-security"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-X9","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3667","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=3667"}],"version-history":[{"count":21,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3667\/revisions"}],"predecessor-version":[{"id":3763,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3667\/revisions\/3763"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=3667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=3667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=3667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}