Страница 1 из 1

потеря прав после backup/restore

Добавлено: 07 дек 2013, 16:45
kisa
День добрый!

Помогите пожалуйста разобраться с небольшой проблемой с правами, которые
пропадают после backup/restore.

Ситуация: есть бд FirebirdSS-1.0.3.972-0, которая активно используется порядка
10 лет. бд непрерывно развивается, что-то удаляется, что-то добавляется.

После очердного backup/restore появился баг: исчезли права select на одну из
таблиц у всех ролей. Причем, если просматривать права роли через IBExpert, то
права select на месте, а по факту прочитать из таблицы ничего не получается -
ошибка нет прав. Помогает исправить ситуацию только единственная последовательность
действий: revoke/grant права select у роли для таблицы. Ничего другое не помогает:
просто grant не помогает, заново дать grant всей роли пользователю не помогает.

Немного позже появилась похожая проблема, только действующие лица уже
не роль и таблица, а процедура (назовем ее public) и другая процедура (внутренняя).
Public процедуре сделан autogrant, и она используют внутреннюю процедуру. Пользователи
используют public и в один прекрасный день после backup/resore не смогли ее вызывать,
из-за отсутствия прав на внутреннюю процедуру. Помог тот же revoke/grant внутренняя to/from
public.

Что это? Куда копать?
Спасибо.

P.S. сегодня решил попробовать сделать копию роли, у которой были потери прав.
После backup/restore получил теже самые грабли.

Re: потеря прав после backup/restore

Добавлено: 07 дек 2013, 23:11
kisa
Попробовал перевести базу на fb 2.1.
Сделал backup/restore, исправил кодировку метаданных и получил
тот же дурдом с правами.

Пример: выполняю простой зарос обновления одной записи с таблице 1.
Получаю ошибку, что нет доступа на чтение таблицы 2. Проверяю триггеры
таблицы 1, делаю на всякий случай еще раз autogrant. Не помогает.
С мыслями, что может быть ошибка в autogrant'е даю права на чтение таблицы 2
тригеру таблицы 1. Помогает. Делаю backup/restore. Снова нет прав. Убираю
права на чтение таблицы 2 у триггера таблицы 1. Помогает!! Т.е. похоже любое
дерганье прав проблемной таблицы, даже удаление прав с этой таблицы, помогает
первоначальному запросу, который из нее и не пытается читать, избежать ошибки.

P.S. да, версия, что достаточно просто дернуть права таблицы 2 у объекта, который не имеет отношения к запросу, который выдает ошибку, оказалось верной. попробовал дать права на таблицу другому пользователю и все ок, первый пользователь, выполняющий запрос больше не получает ошибку.

Re: потеря прав после backup/restore

Добавлено: 08 дек 2013, 00:04
hvlad
Имя таблицы и\или триггера более 27 символов ?

Re: потеря прав после backup/restore

Добавлено: 08 дек 2013, 15:22
kisa
Да, 30 символов имя таблицы

Re: потеря прав после backup/restore

Добавлено: 08 дек 2013, 16:35
hvlad
Этот баг исправлен в FB 2.5
До FB 2.5 не рекомендуется давать имена объектам более 27 символов

Re: потеря прав после backup/restore

Добавлено: 10 дек 2013, 17:39
kisa
Влад, спасибо.

А подскажите пожалуйста, 2.5 это стабильная ветка?

Re: потеря прав после backup/restore

Добавлено: 10 дек 2013, 23:11
hvlad
kisa писал(а):А подскажите пожалуйста, 2.5 это стабильная ветка?
2.5.0 вышел в 2010 году, уже есть 3 пост-релиза: 2.5.1, 2.5.2 и 2.5.2 Update 1, готовится к выходу 2.5.3
Это достаточно, чтобы считаться стабильной веткой ? :)