не работают привилегии после бэкапа

Access Violation, некорректное выполнение запросов или вызовов API, ошибки утилит командной строки, в общем все, что вам мешает работать

Модераторы: kdv, dimitr

Ответить
Krants
Сообщения: 8
Зарегистрирован: 19 дек 2007, 11:56

не работают привилегии после бэкапа

Сообщение Krants » 04 янв 2010, 18:06

Проблема такова, после Restore/Backup базы перестает работать заданное право на изменение одной таблицы.

На таблицу заданы разрешения на Select, Update и Insert для нескольких пользователей, но Update ни у кого из них(кроме SYSDBA) не возможен.
no permission for update/write access to table MYTABLE

IBExpert(Менеджер прав) да и запрос "select * from RDB$USER_PRIVILEGES where rdb$relation_name='MY_TABLE'"
показывает что такое право есть!

Выхожу из этой проблемы странным способом: если под SYSDBA снять/назначить, к примеру право Select для любого пользователя, то право Update начинает работать для всех нормально.

Но после очередного Restore/Backup такой-же баг...

Может кто-то сталкивался с такой проблемой?

Таблица с одним тригером для генератора, вторичных ключей не имеет, отдельно на поля привилегий нету.
FireBird 1.55 (SuperServer)

Krants
Сообщения: 8
Зарегистрирован: 19 дек 2007, 11:56

Re: не работают привилегии после бэкапа

Сообщение Krants » 05 янв 2010, 13:54

Ха, разобрался, - отловил интересный баг в FireBird 1.5.

Причиной ошибки как ни странно стали:
- длинное имя таблицы, 30 символов
- и еще одна таблица с почти таким же именем(кроме последнего символа)

если покапаться в системных таблицах и немного интернете, то обнаружится что структура хранения привилегий базируется на специальном классе RDB$SECURITY_CLASS

RDB$SECURITY_CLASSES - классы безопасности. На эту таблицу идут ссылки их таблиц, полей, процедур и других объектов, где может понадобиться как-то ограничивать права доступа.
где
RDB$SECURITY_CLASS - имя класса. Обычно генерируется автоматически в формате RDB$ЧЕГО_НИБУДЬ.

Реально поле RDB$SECURITY_CLASS является связующим ключем с таблицей RDB$RELATIONS и автоматически генерируется в формате SQL$ЧЕГО_ТО_ТАМ.
Имея максимальную длину 31 символа и приставку "SQL$" этот класс автоматически сгенерировался для двух таблиц с одинаковым именем.
Из за чего и получился баг, - в таблице RDB$RELATIONS оказались две записи с одинаковым "секьюрити" классом.
Ну и при проверке привилегий сервер получал информацию не для той таблицы...

из чего следует, что имена обьектов в FB 1.5 рекомендуется задавать не более 27 символов...

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

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: не работают привилегии после бэкапа

Сообщение hvlad » 05 янв 2010, 14:10

Проблема давно известна и решена в FB 2.5

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: не работают привилегии после бэкапа

Сообщение kdv » 06 янв 2010, 16:57

про 27 символов действительно известно очень давно, и в первую очередь про имена FK.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя