Mysql Регулярное выражение в привилегиях таблиц mysql

[ToD]

Создаю пользователя с правами SELECT.
Нужно, чтоб он имел доступ к таблицам вида pac_******
Таблицы могут быть несозданы, поэтому явно перечислить их не выйдет.
Как использовать регулярное выражение в запросе?
Спасибо

 

[c0dex]

http://lists.mysql.com/mysql/202610 ?

 

[AnrDaemon]

Создаю пользователя с правами SELECT.
Нужно, чтоб он имел доступ к таблицам вида pac_******
Таблицы могут быть несозданы, поэтому явно перечислить их не выйдет.
Как использовать регулярное выражение в запросе?
Спасибо

Добавлю к тому, что сказал c0dex, явно перечислять таблицы НУЖНО.
Иначе получаем дыру в безопасности. Кто-то случайно создаст таблицу с именем, попадающим под твою маску, и вуаля - пользователь имеет доступ к данным, к которым ему доступа не полагалось.

 

[ToD]

http://lists.mysql.com/mysql/202610 ?

Спасибо, но немного не то. Мне нужно указать регулярное выражение в запросе "GRANT SELECT ON..." чтоб пользователю дать право SELECT на определенные таблицы, соответствующие регулярному выражению. Таблицы могут быть такие, которые пока нет в базе. Это вообще возможно в принципе?

 

[ToD]

Добавлю к тому, что сказал c0dex, явно перечислять таблицы НУЖНО.
Иначе получаем дыру в безопасности. Кто-то случайно создаст таблицу с именем, попадающим под твою маску, и вуаля - пользователь имеет доступ к данным, к которым ему доступа не полагалось.

Если нельзя так, то буду думать как решить проблему иначе. Спасибо за информацию.

 

[c0dex]

Можно или нет - не подскажу, просто мне ни разу не приходилось задумываться о разграничении доступа к данным на уровне движка mysql. Мне проще было всегда написать все на уровне приложения.

 

[ToD]

Можно или нет - не подскажу, просто мне ни разу не приходилось задумываться о разграничении доступа к данным на уровне движка mysql. Мне проще было всегда написать все на уровне приложения.

Я делаю сайт-визитку.
Хочу отобразить свежие данные на сайте, и чтоб они брались из рабочей базы данных.
Для дополнительной безопасности решил сделать так.
Но, видимо, придется подключаться через рабочее имя и обеспечить безопасность на уровне приложения.

 

[c0dex]

ToD, а не думал создать отдельного пользователя, отдельную базу данных, сделать пользователю туда доступ и ковыряться дальше уже не парясь о хрени, вроде регулярок к правах доступа? =)

 

[ToD]

c0dex, думал) создать отдельную базу для случайного пользователя сайта, чтоб туда дублировались таблицы из основной базы данных, по-моему, жирновато)
Поэтому, лучше внедрю рабочего пользователя.

 

[c0dex]

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

 

[ToD]

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

А я так не планировал. Ситуация такая.
Я программист-любитель. Основная профессия - медицина. Программирование мое хобби.
Написал скрипты с базой для ведения учета пациентов. База имеет отдельное название.
Запись приема пациентов хранится в виде pac_apr_2015. Каждый раз, когда месяц меняется, автоматом создается новая таблица.
Так вот, идеально мне было бы внедрение регулярки pac_**** для доступа SELECT к таблицам рабочей базы, подключение к которой было бы на сайте.

 

[AnrDaemon]

Идеально не маяться дурью и вернуть все записи в одну таблицу.

 

[c0dex]

ToD, Как сказал уже тов. AnrDaemon, тебе бы вернуть все записи в одну таблицу, где сделать поле с датой приема, то есть DATE, где писать что прием был 2015-01-22, другой там 2015-01-29 и т.д. Не будет проблем с всей этой головной болью, а волосы будут мягкими и шелковистыми (с) реклама.

 

[ToD]

ToD, Как сказал уже тов. AnrDaemon, тебе бы вернуть все записи в одну таблицу, где сделать поле с датой приема, то есть DATE, где писать что прием был 2015-01-22, другой там 2015-01-29 и т.д. Не будет проблем с всей этой головной болью, а волосы будут мягкими и шелковистыми (с) реклама.

Да) Это было бы гораздо лучше, но, к сожалению, понял это потом... Много скриптов завязано. Перебирать пока не буду, если в отдаленной перспективе.