В mysql, "объяснить ..." всегда безопасно? - PullRequest
3 голосов
/ 09 января 2011

Если я разрешу группе пользователей отправлять "explain $whatever" в mysql (через DBI Perl с использованием DBD::mysql), есть ли что-нибудь, что пользователь мог бы положить в $ все, что могло бы внести какие-либо изменения в базу данных, утечку нетривиальной информацииили даже вызвать значительную нагрузку на базу данных?Если да, то как?

Я знаю, что с помощью "explain $whatever" можно выяснить, какие таблицы / столбцы существуют (хотя вы должны угадать имен) и примерно, сколько записей втаблица или сколько записей имеют конкретное значение для индексированного поля.Я не ожидаю, что кто-либо сможет получить какую-либо информацию о содержимом неиндексированных полей.

DBD::mysql не должен разрешать множественные операторы, поэтому я не ожидаю, что можно будет выполнить любой запрос (простообъясните один запрос).Даже подзапросы не должны выполняться, просто объяснил.

Но я не эксперт по mysql, и, конечно, есть некоторые особенности mysql, о которых я даже не подозреваю.

В попытке прийтив соответствии с планом запроса, может ли оптимизатор фактически выполнить выражение, чтобы найти значение, с которым будет сравниваться индексированное поле?

explain select * from atable where class = somefunction(...)

, где atable.class индексируется и не является уникальными class='unused' не найдет записей, но class='common' найдет миллион записей.Можно ли «объяснить» оценку somefunction(...)?И тогда можно ли записать somefunction(...) так, чтобы он изменял данные?

Ответы [ 3 ]

6 голосов
/ 09 января 2011

«Объяснение» может выполняться произвольно долго и использовать произвольное количество серверных ресурсов, в том числе вызывать его сбой, если некоторые вещи исчерпаны (например, переполнение стека, вызванное слишком большим количеством вложенных подзапросов).

«Объяснение» может легко исчерпать временное дисковое пространство, адресное пространство сервера (в 32-разрядных системах, виртуальную память в 64-разрядных системах) или стек потоков (для запросов, созданных намеренно злонамеренно).

В общем, вы не можете разрешить совершенно ненадежным пользователям отправлять какую-либо часть любого SQL вообще. Даже не имея доступа к одной таблице, они, вероятно, все равно могут привести к сбою сервера, если будут стараться.


РЕДАКТИРОВАТЬ: дополнительная информация

Запрос, который использует анонимное представление / материализованный подзапрос, часто выполняет весь внутренний запрос после EXPLAIN во временную таблицу.

Итак, запросы вида

SELECT * FROM (
  SELECT h1.*, h2.* FROM huge_table h1, huge_table h2) AS rediculous

понадобится вечность, чтобы объяснить и использовать место на диске в tmpdir.

3 голосов
/ 11 января 2011

Я смог использовать 'объяснение', чтобы получить точное количество строк, соответствующих точным запросам.Таким образом, можно использовать

explain select * from user where name='tye' and secret like '%a%'

, чтобы быстро определить буквы любого «секрета», а затем перейти к определению порядка букв, в конечном итоге раскрывая значение «секрета».

1 голос
/ 09 января 2011

Если вы хотите, чтобы пользователи могли подключаться к базе данных, но не изменяли ее, вы должны принудительно использовать привилегии пользователей - если у них есть только привилегии SELECT, они не должны ничего менять.

...