потеря прав после backup/restore
потеря прав после backup/restore
День добрый!
Помогите пожалуйста разобраться с небольшой проблемой с правами, которые
пропадают после 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 получил теже самые грабли.
Помогите пожалуйста разобраться с небольшой проблемой с правами, которые
пропадают после 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
Попробовал перевести базу на fb 2.1.
Сделал backup/restore, исправил кодировку метаданных и получил
тот же дурдом с правами.
Пример: выполняю простой зарос обновления одной записи с таблице 1.
Получаю ошибку, что нет доступа на чтение таблицы 2. Проверяю триггеры
таблицы 1, делаю на всякий случай еще раз autogrant. Не помогает.
С мыслями, что может быть ошибка в autogrant'е даю права на чтение таблицы 2
тригеру таблицы 1. Помогает. Делаю backup/restore. Снова нет прав. Убираю
права на чтение таблицы 2 у триггера таблицы 1. Помогает!! Т.е. похоже любое
дерганье прав проблемной таблицы, даже удаление прав с этой таблицы, помогает
первоначальному запросу, который из нее и не пытается читать, избежать ошибки.
P.S. да, версия, что достаточно просто дернуть права таблицы 2 у объекта, который не имеет отношения к запросу, который выдает ошибку, оказалось верной. попробовал дать права на таблицу другому пользователю и все ок, первый пользователь, выполняющий запрос больше не получает ошибку.
Сделал backup/restore, исправил кодировку метаданных и получил
тот же дурдом с правами.
Пример: выполняю простой зарос обновления одной записи с таблице 1.
Получаю ошибку, что нет доступа на чтение таблицы 2. Проверяю триггеры
таблицы 1, делаю на всякий случай еще раз autogrant. Не помогает.
С мыслями, что может быть ошибка в autogrant'е даю права на чтение таблицы 2
тригеру таблицы 1. Помогает. Делаю backup/restore. Снова нет прав. Убираю
права на чтение таблицы 2 у триггера таблицы 1. Помогает!! Т.е. похоже любое
дерганье прав проблемной таблицы, даже удаление прав с этой таблицы, помогает
первоначальному запросу, который из нее и не пытается читать, избежать ошибки.
P.S. да, версия, что достаточно просто дернуть права таблицы 2 у объекта, который не имеет отношения к запросу, который выдает ошибку, оказалось верной. попробовал дать права на таблицу другому пользователю и все ок, первый пользователь, выполняющий запрос больше не получает ошибку.
Re: потеря прав после backup/restore
Имя таблицы и\или триггера более 27 символов ?
Re: потеря прав после backup/restore
Да, 30 символов имя таблицы
Re: потеря прав после backup/restore
Этот баг исправлен в FB 2.5
До FB 2.5 не рекомендуется давать имена объектам более 27 символов
До FB 2.5 не рекомендуется давать имена объектам более 27 символов
Re: потеря прав после backup/restore
Влад, спасибо.
А подскажите пожалуйста, 2.5 это стабильная ветка?
А подскажите пожалуйста, 2.5 это стабильная ветка?
Re: потеря прав после backup/restore
2.5.0 вышел в 2010 году, уже есть 3 пост-релиза: 2.5.1, 2.5.2 и 2.5.2 Update 1, готовится к выходу 2.5.3kisa писал(а):А подскажите пожалуйста, 2.5 это стабильная ветка?
Это достаточно, чтобы считаться стабильной веткой ?