Как ОТМЕНИТЬ РОЛЬ, ПРЕДОСТАВЛЕННУЮ Другим пользователем в Firebird 2.5.8?

Я работаю с Firebird 2.5.8, ODS версии 11.2, подключаюсь через Firebird ADO.NET v6.6 (на С# с использованием Visual Studio). Я создал инструмент управления базой данных для настройки наших таблиц, а также для выполнения некоторых основных операций управления пользователями Firebird. В базе данных есть разные роли (MyRoleX и MyRoleY), определенные для предоставления/ограничения доступа.

Операции по управлению пользователями включают предоставление/отзыв этих ролей различным пользователям. При входе в инструмент соединение использует РОЛЬ АДМИНИСТРАТОРА RDB$, а подключенный пользователь был создан с РОЛЬЮ АДМИНИСТРАТОРА. Наконец, может быть более одного пользователя Firebird (например, Mgr1 и Mgr2).

Итак, Mgr1 СОЗДАЕТ нового пользователя вместе с:

GRANT MyRoleX TO UserA;
GRANT MyRoleY TO UserA;

Затем Mgr1 не работает/отпуск/недоступен, а Mgr2 понимает, что UserA не должен был предоставлять MyRoleY. Но когда Mgr2 входит в систему и пытается выполнить команду:

REVOKE MyRoleY FROM UserA;

выдается сообщение об ошибке:

unsuccessful metadata update
Mgr2 is not grantor of Role on MyRoleY to UserA.

и если команда изменена на:

REVOKE MyRoleY FROM UserA GRANTED BY Mgr1;

то выдается сообщение об ошибке:

unsuccessful metadata update
Only SYSDBA or database owner can use GRANTED BY clause.

Хотя 2-е сообщение явно ясно, почему, если и Mgr1, и Mgr2 подключены с использованием ROLE=RDB$ADMIN (и, конечно, этим пользователям предоставлена ​​РОЛЬ ADMIN), они НЕ могут выполнить эту операцию?

Из Заявление об отзыве привилегий, под заголовком «Отзыв предоставленных привилегий» говорится:

текущий пользователь должен войти в систему с полными административными привилегиями

Если вы вошли в систему под RDB$ADMIN, разве это не полные права администратора?

В верхней части ссылки под заголовком 'Роль RDB$ADMIN', также указано:

Назначение роли RDB$ADMIN обычному пользователю в базе данных предоставляет этому пользователю привилегии SYSDBA.

Так почему же тогда у Mgr2 такие привилегии, как у SYSDBA?

Некоторые вопросы, требующие ответов:

  1. Я делаю что-то не так здесь? Есть ли способ подключить или разрешить Mgr2 ОТМЕНЯТЬ ПРЕДОСТАВЛЕНИЯ ГРАНТОВ РОЛЯМ, созданным Mgr1?

  2. Мы НЕ хотим делиться учетными данными SYSDBA или владельца базы данных для выполнения этих операций, так что есть ли другие решения?


firebird firebird2.5
person David Carr    schedule 15.08.2019    source источник
comment
Я удалил ваш третий вопрос, поскольку он слишком расширяет сферу охвата на «слишком широкую» территорию. Обычно вопрос должен содержать только один вопрос, но оставшиеся два настолько тесно связаны, что по сути представляют собой один вопрос.   -  person Mark Rotteveel    schedule 15.08.2019
comment
попробуйте select CURRENT_ROLE from rdb$database непосредственно перед отзывом - ДЕЙСТВИТЕЛЬНО ли соединение получает ту роль, которую, по вашему мнению, оно получает?   -  person Arioch 'The    schedule 15.08.2019
comment
Спасибо @Arioch'The за указание на это (и ваш ответ ниже). Я создал новый пост по этому конкретному вопросу CURRENT_ROLE: stackoverflow.com/questions/57514744/   -  person David Carr    schedule 15.08.2019
comment
попробуй повторить мой эксперимент твоими инструментами. Установите FB 2.5.9 (вы все равно не получите никаких исправлений в 2.5.8, если это все равно окажется ошибкой сервера), затем воспроизведите, используя ваш язык программирования и библиотеки вашей базы данных программирования, последовательность из трех шагов моей эксперимент. В результате мы можем сосредоточиться на обнаружении различий - либо между вашей и нашей средами, либо между этой правильно работающей последовательностью действий с тремя соединениями и некоторой другой последовательностью, которую делают ваши программы, когда они терпят неудачу. Вам нужно сравнить эталон со своими программами и устранить различия.   -  person Arioch 'The    schedule 16.08.2019

Ответы (1)


arrow_upward
2
arrow_downward

Поскольку в примечаниях к выпуску Firebird 2.5.9 не упоминаются какие-либо исправления, связанные с предоставлением прав пользователям, я думаю, вы что-то ошиблись, возможно, вы просто не вызвали RDB$ADMIN при входе в систему с помощью Mgr2. Попробуйте запросить активную роль непосредственно перед попыткой отзыва.

Только что попробовал это в Firebird 2.5.9 Win64, используя пакет IBExpert.

Первая сессия:

/*** connected as SYSDBA with no role specified ***/
GRANT RDB$ADMIN TO ADM_1;
GRANT RDB$ADMIN TO ADM_2;
CREATE ROLE USER_ROLE;

Второй сеанс:

/*****  ADM_1 with RDB$ADMIN role specified *****/
select current_role, current_user from rdb$database;
-- ROLE         USER
-- RDB$ADMIN    ADM_1

grant user_role to user_1;
grant user_role to user_2 granted by sysdba;

Третий сеанс:

/*****  ADM_2 with RDB$ADMIN role specified *****/
select current_role, current_user from rdb$database;
-- ROLE         USER
-- RDB$ADMIN    ADM_2

revoke user_role from user_2 granted by sysdba;
-- OK

revoke user_role from user_1;
-- This operation is not defined for system tables.
-- unsuccessful metadata update.
-- ADM_2 is not grantor of Role on USER_ROLE to USER_1.

revoke user_role from user_1 granted by adm_1;
-- OK

Так что хоть в 2.5.9 SuperServer с одиночным подключением к БД - просто работает.

P.S. поскольку у вас может быть гораздо больше администраторов, чем два, и поскольку НЕСКОЛЬКО администраторов могут предоставить роль пользователю, и тогда КАЖДЫЙ из этих грантов должен быть найден и отозван один за другим, поэтому я предлагаю для вашего сценария у вас есть выделенный пользователь, и все гранты выдаются от его имени, как я сделал с SYSDBA во втором сеансе.

person Arioch 'The    schedule 15.08.2019