SYBASE (Задания по бд), страница 12

Команда setuser

Для “отображения” характеристик другого пользователя и его полномочий ВБД может использовать команду setuser. С помощью этой команды ВБД может получить доступ к объекту, которым владеет другой пользователь, предоставить полномочия на объект, которым владеет другой пользователь, создать объект, которым будет владеть другой пользователь, временно получить полномочия другого пользователя и другие.

СА может использовать команду setuser для того, чтобы создавать объекты, которыми будет владеть другой пользователь. Однако, СА, владея системными полномочиями, не может приобретать полномочия других пользователей.

Синтаксис команды:

setuser [“<имя пользователя>”]

Пример: предоставить полномочие joe на чтение таблицы authors, которой владеет mary.

Setuser “mary”

grant select on authors to joe

Полномочия владельцев объектов БД

Владелец объектов БД создает объект БД с помощью команды create и автоматически становится владельцем этого объекта, получает все полномочия на этот объект. Другие пользователи, включая владельца БД, автоматически лишаются всех полномочий на этот объект до тех пор, пока им не предоставит полномочия владелец объекта или другой пользователь, имеющий grant-полномочие на этот объект.

Пример: mary объявляется владельцем БД pubs2 и передает полномочие joe на создание таблиц в этой БД. Joe создает таблицу new_authors и становится владельцем этой таблицы. Joe может предоставить и отменить полномочия на эту таблицу другим пользователям, включая mary и владельца БД. (Однако, ВБД может применить команду setuser).

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

1. alter table;

2. drop table;

3. create index;

4. create trigger;

5. truncate table;

6. update statistics.

Полномочие на использование команд grant и revoke, чтобы предоставлять полномочия пользователям на использование команд select, insert, update, delete, references и execute, передается с помощью команды grant with grant option.

Полномочие на команду drop (уничтожение) объекта предоставляется только владельцу объекта и никому не передается.

Полномочия конечных пользователей

КП определяются именем пользователя, именем группы или ключевым словом “public” в командах grant или revoke, выдаваемых СА, ВБД, ВОБД или пользователями с полномочиями использования with grant option.

Командные и объектные полномочия

Существует два вида полномочий, назначаемых с помощью grant/revoke:

- объектные полномочия;

- командные полномочия.

Объектные полномочия контролируют использование некоторых команд, применяемых к объектам БД, и некоторых объектов БД. Это следующие команды и объекты:

По умолчанию, объектные полномочия предоставляются СА и ВОБД, а остальным пользователям - с помощью команды grant.

Командные полномочия - это полномочия на выполнение следующих команд:

- create database;

- create default;

- create procedure;

- create rule;

- create table;

- create view.

Эти полномочия могут быть предоставлены только СА и ВБД(исключая create database).

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

Если пользователь попытается использовать команду или объект БД, на которые у него нет полномочий, то SQL-сервер выдаст сообщение об ошибке.

Команды grant и revoke

Командные и объектные полномочия предоставляются с помощью команды grant, а отменяются - с помощью команды revoke.

Синтаксис команд grant и revoke для предоставления и отмены командных полномочий:

grant {all [privileges] | <список команд>}

to {public|<список имен пользователей>|<название роли>}

revoke {all [privileges] | <список команд>}

from {public|<список имен пользователей>|<название роли>}

<список команд> - это одна или более команд типа create; если указывается all, то это означает, что все указанные выше команды create предоставляются или отменяются для указанных пользователей.

Синтаксис команд grant и revoke для предоставления и отмены объектных полномочий:

grant {all [privileges] | <список полномочий>}

on {<имя таблицы>[(<список колонок>)]|

<имя представления>[(< список колонок>)]|

<имя хранимой процедуры>}

to {public|<список имен пользователей>|<название роли>}

[with grant option]

revoke [grant option for]

{all [privileges] | <список полномочий>}

on{<имя таблицы>[(<список колонок>)]|

<имя представления>[(<список колонок>)]|

<имя хранимой процедуры>}

from {public|<список имен пользователей>|<название роли>}

[cascade]

1. Использование опции all вместо списка полномочий разрешается только системному администратору.

2. Если вы предоставляете/отменяете полномочия на таблицу или представление без указанных колонок, то список полномочий может включать любую комбинацию команд select, insert, delete, references и update.

3. Если вы указываете колонки, то список привилегий может включать только select, references и update (команды insert и delete включать нельзя).

4. Если вы предоставляете полномочие на использование хранимых процедур, то список привилегий состоит из одной команды execute (либо all, что является тем же самым, что и execute).

5. Структура on определяет объект, на который предоставляется/отменяется полномочие.

6. Ключевое слово public обозначает группу пользователей “public”, включающую всех пользователей SQL-сервера.

7. <список имен пользователей> - это список имен: а) групп; б) пользователей; в) комбинаций имен групп и пользователей.

8. <название роли> - это sa_role (для СА), sso_role (для УСЗ), oper_role (для оператора).

9. Структура with grant option определяет, что пользователи, указанные в <списке имен пользователей> получают право предоставлять полномочия другим пользователям, а опция grant option for - отменяет это.

10. Опция cascade в команде revoke отменяет объектные полномочия пользователей, указанных в <списке имен пользователей>, а также пользователей, которые предоставили эти полномочия указанным пользователям.

Примеры:

1) Предоставить полномочия пользователю VAF выполнять команды update, insert и delete в таблице poss:

grant update, insert, delete

on poss

to VAF

2) Предоставить привилегию пользователю VAF на запуск хранимой процедуры ZAPR5:

grant execute

on zapr5

to VAF

3) Предоставить полномочия пользователям APB, VAF на выполнение команд create table, create view

grant create table, create view

to APB, VAF

4) Отменить полномочия пользователя АРВ на выполнение команд create table, create view

revoke create table, create view

from APB

Получение информации о полномочиях

Для получения информации о командных и объектных полномочиях используются три системные процедуры: sp_helprotect, sp_column_privileges, sp_table_privileges.

Системная процедура sp_helprotect выдает информацию о полномочиях на объект БД, о полномочиях пользователя и о полномочиях пользователя на определенный объект. Синтаксис команды:

sp_helprotect <имя> [, <имя в БД> [, “grant”]]

Параметр <имя> - это или имя таблицы, представления и хранимой процедуры (т. е. имя объекта), или имя пользователя, группы и название роли. Если указан второй параметр <имя в БД>, то выдается информация о полномочиях только этого пользователя. Если указан третий параметр “grant”, а <имя> не является объектом, то выдается информация о всех полномочиях, предоставленных с помощью with grant option.

Системная процедура sp_column_privileges выдает информацию о полномочиях на колонки в таблицах. Синтаксис команды:

sp_table_privileges <имя таблицы> [, <владелец таблицы>

[, <имя активной БД> [, <имя колонки>]]]

Если какой-либо параметр не определяется, то вместо него ставится null, например:

sp_column_privileges publishers, null, null, pub_id

Системная процедура sp_table_privileges выдает информацию о полномочиях на определенную таблицу. Синтаксис команды:

sp_table_privileges <имя таблицы> [, <владелец таблицы> [, <имя активной БД>]]

Аналогично используется слово null.

Пример:

sp_table_privileges titles

Управление ролями в SQL-сервере

Во время инсталляции SQL-сервера ресурс, называемый “sa” (СА), автоматически предоставляется ролям системного администратора, управляющего системной защитой и оператора. Пользователь с привилегией “sa” является владельцем системных БД.

Вы можете использовать “sa” для выполнения всех функций СА и всех защитных функций. Используя “sa”, вы можете создать новые имена клиентов сервера и предоставить им роли СА и УСЗ. Это делается с помощью системной процедуры sp_role. УСЗ может записать свой собственный ресурс, захватить ресурс “sa” (с помощью процедуры sp_locklogin) и создать имена другим клиентам сервера (с помощью процедуры sp_addlogin).

Предоставление ролей СА, УСЗ и О:

sp_role {“grant” | “revoke”}, {sa_role | sso_role | oper_role}, <имя клиента>

Пример:

sp_role “grant”, sa_role, APB

Предоставление роли пользователю осуществляется перед началом его сеанса работы. Однако, сам пользователь может немедленно назначить себе роль в течение сеанса работы, используя команду set role, например:

set role “sa_role” on

И вы не сможете отменить эту роль в течение его сеанса работы. Системные процедуры sp_droplogin, sp_locklogin и sp_role всегда обеспечивают в системе, по крайней мере, одного пользователя, обладающего ролью УСЗ, и одного пользователя, обладающего ролью СА.

Полный синтаксис команды set role:

set role “{sa_role | sso_role | oper_role}” {on | off}

Контроль использования ролей

1) Получение информации о клиентах сервера:

sp_displaylogin [<имя клиента>]

Если вы не УСЗ и не СА, то вы можете получить информацию только о своем собственном ресурсе: свой пользовательский ID, входное имя, полное имя, роли, дату последнего изменения пароля и защищен ли ваш ресурс. А если вы УСЗ или СА, то вы можете получить информацию о любом пользователе, используя <имя клиента>.

2) Функция show_role предоставляет информацию о всех ролях, которые работают во время вашего сеанса работы:

select show_role ()

3) Функция proc_role проверяет предоставленные роли в хранимых процедурах. Если вы владеете ролью СА, то проверка в тексте хранимой процедуры (оператор if) proc_role (“sa_role”) дает в результате 1, иначе - 0. Аналогичные проверки можно делать и для sso_role, и для oper_role.