Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Для предоставления получателю нескольких привилегий к таблице перечислите предоставляемые привилегии в списке, отделяя друг от друга запятыми. Следующий оператор назначает полномочия INSERT и UPDATE К таблице DEPARTMENT пользователю
CHALKY:
GRANT INSERT, UPDATE ON DEPARTMENT TO CHALKY;
Список привилегий может быть любой комбинацией в любом порядке привилегий
SELECT, INSERT, UPDATE, DELETE и REFERENCES. Привилегия EXECUTE должна назначаться в отдельном операторе.
Привилегия REFERENCES не может быть назначена просмотру.
Привилегия ALL
GRANT ALL ON DEPARTMENT TO CHALKY;
Вы также можете назначать пакет ALL триггерам и процедурам. В следующем операторе процедура COUNT_CHICKENS получает полные права к таблице PROJ_DEPT_BUDGET:
GRANT ALL ON PROJ_DEPT_BUDGET TO PROCEDURE COUNT_CHICKENS;
Несколько видов синтаксиса позволяют вам предоставлять привилегии множеству пользователей в одном операторе. Вы также можете назначать привилегии:
* списку именованных пользователей или процедур;
* группе UNIX;
* всем пользователям (PUBLIC);
* роли (затем назначая эту роль списку пользователей, PUBLIC или группе UNIX).
Для назначения одних и тех же привилегий доступа пользователям в одном операторе запищите список пользователей, разделенных запятыми, на месте одного имени пользователя.
Следующий оператор предоставляет полномочия INSERT и UPDATE К таблице DEPARTMENT пользователям MICKEY, DONALD и HPOTTER:
GRANT INSERT, UPDATE ON DEPARTMENTS TO MICKEY, DONALD, HPOTTER;
Для назначения привилегий нескольким процедурам в одном операторе запишите список процедур, разделенных запятыми. Здесь две процедуры получают привилегии в одном операторе:
GRANT INSERT, UPDATE ON PROJ_DEPT_BUDGET
TO PROCEDURE CALCULATE_ODDS, COUNT_BEANS;
Имена учетных записей операционной системы Linux/UNIX доступны для безопасности в Firebird через привилегии Firebird, которые не являются стандартом SQL. Клиент, выполняющийся как пользователь UNIX, применяет этот идентификатор пользователя в базе данных, даже если такая учетная запись не определена в базе данных безопасности Firebird.
Машина, получающая доступ к серверу, должна быть в списке доверенных машин на сервере (файлы /etc/host.equiv или /etc/gds_host.equiv, или в .rhost в домашнем каталоге пользователя на сервере). При соединении пользователь использует идентификацию его группы, если он не предоставил для Firebird свое имя пользователя и пароль в качестве параметров соединения - учетные записи Firebird перекрывают учетные записи UNIX.
Группы Linux/UNIX совместно используют такое поведение: пользователь SYSDBA или Суперпользователь могут назначать привилегии SQL группам UNIX. Любая операция над учетной записью на уровне системы, которая является членом группы, наследует привилегии, предоставленные группе, например:
GRANT ALL ON CUSTOMER TO GROUP sales;
Для назначения одних и тех же привилегий доступа к таблице всем пользователям предоставьте привилегии PUBLIC, PUBLIC только пользователей - не триггеры, процедуры, просмотры или роли.
GRANT SELECT, INSERT, UPDATE ON DEPARTMENT TO PUBLIC;
Привилегии,
предоставленные пользователям с помощью PUBLIC, могут быть отменены только путем отмены их у PUBLIC. Вы не можете, например, отменить привилегию у CHALKY, которую CHALKY получил как член PUBLIC.Привилегии через роли
Процесс реализации ролей состоит из четырех шагов:
1. Создание роли с использованием оператора CREATE ROLE.
2. Назначение привилегий этой роли посредством GRANT привилегия то роль.
3. Назначение роли пользователям посредством GRANT роль то пользователь.
4. Задание роли вместе с именем пользователя при соединении с базой данных.
Создание роли
Синтаксис создания роли прост:
CREATE ROLE <имя-роли>;
Пользователь SYSDBA или владелец базы может создавать роли, предоставлять им привилегии и передавать эти "нагруженные" роли пользователям. Если роль предоставлена с параметром WITH ADMIN OPTION, получатель этой роли может предоставлять ее другим пользователям с WITH ADMIN OPTION или без.
Назначение привилегий роли
Для "загрузки" роли привилегиями просто предоставьте ей требуемые привилегии, как если бы роль была обычным пользователем:
GRANT <привилегии> ТО <имя-роли>;
Предоставление роли пользователям
В операторе GRANT для предоставления роли пользователям опускается предложение ON- здесь неявно используются полномочия, "загруженные" в роль.
GRANT <имя-роли> [, <имя-роли> [, ...]]
TO [DSER] <имя-пользователя> [, [OSER] <имя-пользователя> [, ...]] [WITH ADMIN OPTION];
Необязательное предложение WITH ADMIN OPTION позволяет получающему роль предоставлять эту роль другим пользователям, а также отменять ее. Это работает таким же образом, что и WITH GRANT OPTION для обычных полномочий - см. разд. "Предоставление прав на предоставление привилегий".
Следующий пример создает роль MAITRE D, предоставляет этой роли привилегии ALL К таблице DEPARTMENT, а затем предоставляет роль пользователю HORTENSE. Это дает пользователю HORTENSE привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES К таблице DEPARTMENT.
CREATE ROLE MAITRE_D;
COMMIT;
GRANT ALL
ON DEPARTMENT
TO MAITRE_D;
GRANT MAITRE_D TO HORTENSE;
Подключение к базе данных с использованием роли
При соединении включите ROLE в список параметров соединения и укажите ту роль, чьи привилегии вы хотите использовать в этом соединении. Это будет работать, только если данному пользователю была предоставлена указанная роль:
CONNECT <путь-к-базе-данных>
USER <ваше-имя-пользователя>
ROLE <имя-роли>
PASSWORD <ваш-пароль>;
Удаление роли
Если вы удаляете роль, то все привилегии, предоставленные этой роли, отменяются. Чтобы удалить роль MAITRE_D, выполните:
DROP ROLE MAITRE D;
! ! !
ПРИМЕЧАНИЕ. Если вам нужно лишь удалить привилегии, предоставленные пользователю с помощью роли, или удалить привилегии роли, используйте оператор REVOKE (см. разд. "Отмена полномочий").
. ! .
Предоставление прав на предоставление привилегий