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

Запросы, планы, оптимизация запросов, ...

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

Ответить
kisa
Сообщения: 7
Зарегистрирован: 28 окт 2009, 17:48

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

Сообщение kisa » 07 дек 2013, 16:45

День добрый!

Помогите пожалуйста разобраться с небольшой проблемой с правами, которые
пропадают после 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 получил теже самые грабли.

kisa
Сообщения: 7
Зарегистрирован: 28 окт 2009, 17:48

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

Сообщение kisa » 07 дек 2013, 23:11

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

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

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

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

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

Сообщение hvlad » 08 дек 2013, 00:04

Имя таблицы и\или триггера более 27 символов ?

kisa
Сообщения: 7
Зарегистрирован: 28 окт 2009, 17:48

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

Сообщение kisa » 08 дек 2013, 15:22

Да, 30 символов имя таблицы

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

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

Сообщение hvlad » 08 дек 2013, 16:35

Этот баг исправлен в FB 2.5
До FB 2.5 не рекомендуется давать имена объектам более 27 символов

kisa
Сообщения: 7
Зарегистрирован: 28 окт 2009, 17:48

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

Сообщение kisa » 10 дек 2013, 17:39

Влад, спасибо.

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

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

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

Сообщение hvlad » 10 дек 2013, 23:11

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

Ответить