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

Вы можете задать только ключевые столбцы и, возможно, сохранить некоторую избыточность, если первичная таблица содержит очень много столбцов. Если вы сделаете так, вы должны задать все связанные ключевые столбцы. Упрощенный синтаксис выглядит так:

GRANT REFERENCES

ON <первичная-таблица> [ (<ключевой-столбец>

[, <ключевой-столбец> [, . . . ] ] ) ]

ТО <пользователь>

[WITH GRANT OPTION] ;

Следующий пример предоставляет привилегии REFERENCES К таблице DEPARTMENTS пользователю CHALKY, позволяя CHALKY записывать внешний ключ, который ссылается на первичный ключ таблицы DEPARTMENTS, даже если он не владеет этой таблицей:

GRANT REFERENCES ON DEPARTMENTS (DEPT_NO) TO CHALKY;

! ! !

СОВЕТ. Если видимость ключей не является проблемой, предоставьте привилегии REFERENCES для PUBLIC

. ! .

Привилегии к объектам

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

С другой стороны, привилегии к таблице могут быть предоставлены процедуре, а не индивидуальным пользователям для повышения безопасности. Пользователю нужна только привилегия EXECUTE к процедуре, которая осуществляет доступ к таблице.

Хранимой процедуре, просмотру или триггеру иногда нужны привилегии для доступа к таблице или просмотру, которые имеют другого владельца. Для предоставления привилегий триггеру или хранимой процедуре включите соответствующее ключевое слово TRIGGER или PROCEDURE перед именем модуля.

В следующем примере процедуре COUNT_CHICKENS предоставляются полномочия INSERT к таблице PROJ_DEPT_BUDGET:

GRANTINSERTON PROJ_DEPT_BUDGETTO PROCEDURE COUNT_CHICKENS;

Предоставление привилегии EXECUTE

Для использования хранимой процедуры пользователям, триггерам или другим хранимым процедурам нужна к ней привилегия EXECUTE. ЕСЛИ просмотр выбирает выходные поля из хранимой процедуры выбора, просмотр должен иметь привилегию

EXECUTE, а не привилегию SELECT.

Упрощенный синтаксис выглядит следующим образом:

GRANT EXECUTE

ON PROCEDURE <имя-процедуры> TO <получатель>;

<получатель> = [ PROCEDURE <имя-процедуры> [, <имя-процедуры> [, ..]]] [ TRIGGER <имя-триггера> [, <имя-триггера> [, ...]]] [ VIEW <имя-просмотра> [, <имя-просмотра> [, ...]]] | <имя-роли> | <пользователь-или-список> | PUBLIC [WITH GRANT OPTION];

Хранимой процедуре или триггеру нужна привилегия EXECUTE К хранимой процедуре, если она имеет другого владельца. Помните, что владельцем триггера является пользователь, создавший таблицу.

Если ваш оператор GRANT EXECUTE предоставляет привилегии для PUBLIC, то никакие другие типы получателей привилегий не могут быть представлены в качестве аргументов то.

В следующем примере оператор GRANT EXECUTE предоставляет привилегию к процедуре CALCULATE_BEANS двум обычным пользователям FLAT FOOT и KILROY и Двум Хранимым процедурам, чьи владельцы не являются владельцами CALCULATE_BEANS:

GRANT EXECUTE ON PROCEDURE CALCULATE_BEANS

TO FLATFOOT,

KILROY,

PROCEDURE DO_STUFF, ABANDON_OLD ;

Привилегии к просмотрам

Привилегии к просмотрам являются довольно запутанными. Владелец просмотра должен предоставить пользователям привилегию SELECT, как это сделал бы владелец таблицы. Сложности начинаются, если просмотр является изменяемым - естественным образом или через триггеры просмотра- или если просмотр включает другие просмотры или хранимые процедуры выбора. Изменения данных изменяемого просмотра фактически выполняют изменения в базовых таблицах. Если владельцы базовых объектов еще не предоставили пользователю соответствующих прав (INSERT, UPDATE, DELETE, EXECUTE) к базовым таблицам и объектам, а также к хранимым процедурам выбора или к просмотрам, то пользователю нужно их получить от владельца просмотра.

Привилегии REFERENCES неприменимы к просмотрам за исключением одной (обычно опускаемой) ситуации. Если просмотр использует таблицу, которая имеет внешние ключи, ссылающиеся на другие таблицы, то просмотру нужны привилегии REFERENCES к этим другим таблицам, если эти таблицы сами не используются в данном просмотре.

Подробности см. в разд. "Привилегии" главы 24.

Множество привилегий и множество получателей привилегий

Есть возможность предоставлять несколько привилегий в одном операторе и предоставлять одну или более привилегий множеству пользователей или объектов.

Множество привилегий

Для предоставления получателю нескольких привилегий к таблице перечислите предоставляемые привилегии в списке, отделяя друг от друга запятыми. Следующий оператор назначает полномочия INSERT и UPDATE К таблице DEPARTMENT пользователю

CHALKY:

GRANT INSERT, UPDATE ON DEPARTMENT TO CHALKY;

Список привилегий может быть любой комбинацией в любом порядке привилегий

SELECT, INSERT, UPDATE, DELETE и REFERENCES. Привилегия EXECUTE должна назначаться в отдельном операторе.

Привилегия REFERENCES не может быть назначена просмотру.

Привилегия ALL

Привилегия ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES В одном пакете. Например, следующий оператор предоставляет CHALKY полный пакет полномочий к таблице DEPARTMENT:

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;

Группа UNIX

Имена учетных записей операционной системы 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, 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 или без.

Назначение привилегий роли

Для "загрузки" роли привилегиями просто предоставьте ей требуемые привилегии, как если бы роль была обычным пользователем: