Добрый день. Возникла такая проблема.
Имеется пользователь user1, через которого к БД подключается веб-приложение. Имеется пользователь user2. Эти пользователи никак не связаны между собой. Если у пользователя user2 забрать или дать какой-либо грант, то веб-приложение при обращении к БД будет падать с ошибкой о нехватке прав на поле таблицы, хотя до этого работало отлично. После перезапуска веб-приложения оно работает корректно.
Чем может быть вызвано такое поведение? Разве обязательно переподключаться к базе после изменения прав какого-либо пользователя?
Версия FB - 1.5.

Важное замечание: проблема возникает ровно один раз. После обновления коннекта один раз, манипуляции с правами пользователя user2 больше никак не влияют на права пользователя user1.

kdvInterloperРазве обязательно переподключаться к базе после изменения прав какого-либо пользователя?
изменения прав для пользователя А не влияют на пользователя Б.
если у вас есть сценарий воспроизведения проблемы - приводите. Пока похоже на стук в подвале.
Сценарий я описал в первом посте.

Dimitry SibiryakovInterloperЧем может быть вызвано такое поведение?
1) Использование версии Firebird времён царя Гороха.
2) Ошибка в уеб-приложении.
3) Ошибка при выдаче или заюирании какого-то права.

Можете привести примеры ошибок при выдаче или затирании права?
Ошибка возникает после того, как пользователю дается право на select, update на поле таблицы (а не на таблицу целиком).

Вот точная последовательность шагов для воспроизведения ошибки (метаданные разглашать не могу).
1. Подключиться к БД пользователями user1, SYSDBA.
2. Выполнить GRANT SELECT, UPDATE(MYFIELD) ON TABLE1 TO user2 из админского коннекта.
3. Выполнить REVOKE SELECT, UPDATE(MYFIELD) ON TABLE1 FROM user2 из админского коннекта.
4. Выполнить select * from stored_proc1(params) из коннекта user1. Получим ошибку "no permission for read/write to column MYFIELD".
5. Отключиться и подключиться заново пользователем user1.
6. Выполнить select * from stored_proc1(params) из коннекта user1. Ошибка не возникает.

В чем может быть причина?

Вот что нашел в трекере: http://tracker.firebirdsql.org/browse/CORE-4407
По идее моя проблема. Никто не сталкивался?

InterloperВот точная последовательность шагов для воспроизведения ошибки (метаданные разглашать не могу).
1. Подключиться к БД пользователями user1, SYSDBA.
2. Выполнить GRANT SELECT, UPDATE(MYFIELD) ON TABLE1 TO user2 из админского коннекта.
3. Выполнить REVOKE SELECT, UPDATE(MYFIELD) ON TABLE1 FROM user2 из админского коннекта.
4. Выполнить select * from stored_proc1(params) из коннекта user1. Получим ошибку "no permission for read/write to column MYFIELD".
5. Отключиться и подключиться заново пользователем user1.
6. Выполнить select * from stored_proc1(params) из коннекта user1. Ошибка не возникает.

В чем может быть причина?

Вот еще нюанс. Перед шагом 3 нужно выполнить select * from stored_proc1(params) из коннекта user1, ошибки не будет. Зато такой вызов после REVOKE спровоцирует ошибку. Если перед шагом 3 вызова не делать, то ошибку на шаге 4 не получим.
Очень странный баг.

Гаджимурадов Рустам,

Скриптом.

Антон Карасёв,

Решили отказаться от управления правами на уровне полей. На том проблема и решена.