Проблема такова, после 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)
не работают привилегии после бэкапа
Re: не работают привилегии после бэкапа
Ха, разобрался, - отловил интересный баг в 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, то буду признателен за ответ.
Причиной ошибки как ни странно стали:
- длинное имя таблицы, 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, то буду признателен за ответ.
Re: не работают привилегии после бэкапа
Проблема давно известна и решена в FB 2.5
Re: не работают привилегии после бэкапа
про 27 символов действительно известно очень давно, и в первую очередь про имена FK.