Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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 (см. разд. "Отмена полномочий").

. ! .

Вначале только владелец таблицы или просмотра или пользователь SYSDBA могут предоставлять полномочия к этому объекту другим пользователям. Добавьте WITH GRANT OPTION в конец оператора GRANT для передачи пользователю права предоставлять привилегии вместе с самими привилегиями.

Следующий оператор назначает полномочия SELECT пользователю HPOTTER и дает право HPOTTER предоставлять полномочия SELECT другим:

GRANT SELECT ON DEPARTMENT TO HPOTTER WITH GRANT OPTION;

WITH GRANT OPTION не может назначаться триггерам или процедурам.

Права WITH GRANT OPTION являются кумулятивными, даже если передаются различными пользователями. Например, HPOTTER может получить право предоставлять права SELECT к таблице DEPARTMENT от одного пользователя и INSERT К DEPARTMENT от другого.

В следующем примере HPOTTER имеет доступ SELECT К таблице DEPARTMENT с правом передавать полномочия, HPOTTER может предоставлять полномочия SELECT другим пользователям. Предположим, HPOTTER теперь также получает полномочия INSERT к этой же таблице, но без права предоставлять эти полномочия:

GRANT INSERT ON DEPARTMENT TO HPOTTER;

Пользователь HPOTTER может выбирать данные и добавлять данные в таблицу DEPARTMENT. Он может предоставлять полномочия SELECT к таблице DEPARTMENT, но не может назначать полномочия INSERT, потому что он не имеет права предоставлять эту привилегию.