[MDEV-17141] Add variable to block queries to risky information_schema tables Created: 2018-09-05 Updated: 2019-08-03 Resolved: 2019-08-03 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Information Schema |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Major |
| Reporter: | Manjot Singh (Inactive) | Assignee: | Sergei Golubchik |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Customer has had issues when querying tables such as information_schema.innodb_buffer_page and a few others that have the potential to cause production downtime in high concurrency environments. A variable such as super_only_risky_tables to only allow super or root users to query these tables could help negate this risk. Having this variable enabled makes the tables inaccessible for non super users. Another option is a specific grant that does the same thing such as GRANT VERBOSE SCHEMA etc |
| Comments |
| Comment by Ralf Gebhardt [ 2019-03-25 ] |
|
From my point of view it would be better to have tables like innodb_buffer_page or innodb_mutexes in another schema instead. serg, what you do think? |
| Comment by Manjot Singh (Inactive) [ 2019-03-25 ] |
|
I like this idea Ralf! perhaps internal_schema or deep_information_schema. internal_schema would be nice, perhaps it could eventually maintain storage engine statuses or internals. |
| Comment by Sergei Golubchik [ 2019-03-25 ] |
|
No, I don't see a point. SQL Standard already specifies the behavior or I_S tables quite clearly. Everybody can always select from them. But it doesn't mean that everyone will always get the same output. Some users can see more rows than others (think of I_S.TABLES, for example — a user will not see tables he has no privileges on). So I do not see why you're trying to invent more access control layers on top of what I_S already has. |
| Comment by Manjot Singh (Inactive) [ 2019-03-26 ] |
|
The issue is that the storage engine is global regardless of grants and causing load on it causes issues for all. |
| Comment by Ralf Gebhardt [ 2019-03-26 ] |
|
serg, my point was to, instead of having access control layers, to rethink which tables should actually be in the information schema. Are informations given by innodb_buffer_page or innodb_mutexes database meta data an application would be interested in? Or is this information more storage engine dependent? |
| Comment by Sergei Golubchik [ 2019-03-26 ] |
|
Sure not everything that is in the I_S now should be there. But what's got there is kind of difficult to move out. Logically, I_S is for metadata only. We have lots of everything in there, it should be in performance_schema or may be in some third schema even. But I don't see how we can move all these tables out of I_S — it'll break tons of applications. |
| Comment by Julien Fritsch [ 2019-08-02 ] |
| Comment by Sergei Golubchik [ 2019-08-03 ] |
|
According to the standard all tables in information_schema are always readable for anyone |