ЛИНТЕР

Создание пользователя

Функция

Определение оператора создания нового пользователя БД.

Спецификация

< создание пользователя >::=

CREATE [IF NOT EXISTS | OR REPLACE] USER имя пользователя
[IDENTIFIED BY {пароль | SYSTEM | PROTOCOL | LDAP | KRB}]
[LEVEL (RAL, WAL)]
[GROUP имя группы]

< пароль >::=

символьный литерал

< RAL >::=

идентификатор

< WAL >::=

идентификатор

Общие для всех механизмов аутентификации синтаксические правила

Опция OR REPLACE заставляет в случае, если пользователь существует в БД, удалять и пересоздавать его под тем же именем, но с указанными параметрами.
Опция IF NOT EXISTS отменяет выполнение оператора, если указанный пользователь уже существует в БД.
Для создания нового пользователя необходимо иметь уровень прав DBA.
< Имя пользователя > должно быть уникальным среди имен пользователей, схем и ролей БД.
После отправки клиентским приложением имени и пароля пользователя для его идентификации и аутентификации осуществляется их автоматическое преобразование из кодировки клиентского приложения в кодировку словаря БД. Данная операция критична, например, для русских имён пользователей ('Администратор', 'Гость' и т. п.). В этом случае для словаря СУБД ЛИНТЕР должна быть установлена кодировка, отличная от DEFAULT (кодировки по умолчанию), а в системной таблице $$$CHARSET должна присутствовать кодировка, заданная для ОС клиентского приложения.

Например, аутентификация с русскими именами пользователей на русифицированной ОС Windows будет отработана корректно, если для клиентского приложения установлена кодировка "CP866", "CP1251", "KOI8-R" или другая, поддерживающая русские символы, и эта же кодировка присутствует в таблице кодировок БД.
В процессе авторизации пользователю, созданному командой CREATE USER и прошедшему аутентификацию, присваивается CONNECT-категория (т.е. доступ к БД с возможностью подавать SQL-запросы на манипулирование данными с теми объектами БД, владельцы которых предоставили ему такое право).

Примеры

1) это один и тот же пользователь

create user GUEST;
create user guest;
create user "GUEST";

2) это разные пользователи

create user "guest";
create user guest;

Синтаксические правила парольной аутентификации

< Пароль > не должен превышать 18 символов.

< Пароль > регистрозависимый.

Пример

Это разные пароли:

create or replace user guest identified by 'qwerty123';
create or replace user guest identified by 'Qwerty123';

Общие правила парольной аутентификации

Восстановить утерянный < пароль > невозможно.

Примеры

create if not exists user GUEST identified by '12345678';

create user "Гость" identified by 'без пароля';
username "Гость"/"без пароля"

Общие правила аутентификации средствами ОС

Создание пользователя с аутентификацией средствами ОС (встроенная в ОС аутентификация) возможно только в операционных системах, которые поддерживают эту функциональность (семейство Windows NT, SunOS, FreeBSD, Linux). В этом случае в ОС должна быть учётная запись пользователя с таким именем.
В ОС Windows NT пользователь ОС, для которого в базе данных устанавливается режим аутентификации средствами ОС, должен иметь привилегию SE_TCB_NAME («Act as part of the Operating System» – «Работа в режиме операционной системы»).
Конструкция устанавливает для пользователя режим встроенной аутентификации операционной системы. Это означает, что при доступе к БД надо указывать имя, идентичное имени при регистрации в ОС, и тот же пароль, что и при регистрации в ОС. Пароль при этом не хранится в БД. СУБД ЛИНТЕР выполняет только идентификацию пользователя с указанным именем и дает ему и разрешение на доступ к БД, а аутентификацию выполняет ОС.
В UNIX-системах создание пользователя со встроенной аутентификацией выполняется с помощью разделяемой библиотеки PAM (Pluggable Authentication Modules – подключаемые модули аутентификации). Вследствие этого пользователь ОС, от имени которого запускается ядро СУБД ЛИНТЕР, должен иметь доступ на чтение паролей ОС.

Пример

create or replace user "Sakharov" identified by system;
username "Sakharov"/"Password_OS"

Общие правила аутентификации BY PROTOCOL

Конструкция задает идентификацию и аутентификацию пользователя при проверке доступа к БД по имени пользователя, зарегистрированного в ОС.
При запуске клиентских приложений, выполняющих соединение с СУБД ЛИНТЕР, имя пользователя надо задавать пустым (пароль в этом случае запрашиваться не будет).
```
create or replace user "Sakharov" identified by protocol;
inl –u /
```
или
```
inl < Enter >
Имя пользователя   : < Enter >
Пароль пользователя: < Enter >
SQL >
```
Пользователь-владелец БД не может идентифицироваться и аутентифицироваться таким способом.
Доступ к БД будет проверяться от имени текущего пользователя ОС.

Примечание

Создание пользователя с прозрачной аутентфикацией поддерживается в ОС Windows и UNIX, но аутентификация с помощью вышеуказанной конструкции поддерживается только в UNIX-системах.

Общие правила аутентификации с помощью LDAP-сервера

Конструкция устанавливает для пользователя парольный режим контроля доступа через LDAP-сервер. Для успешной идентификации и аутентификации требуется соответствие предъявленного имени и пароля соответствующим атрибутам одного из пользователей в БД LDAP-сервера. При неудачной попытке аутентификации по любой причине (несоответствие пароля, отсутствие пользователя или недоступность LDAP-сервера) возвращается код завершения 1026 «Неверный пароль».
При создании пароля на LDAP-сервере необходимо избегать паролей с конечными пробелами, поскольку они интерпретируются СУБД ЛИНТЕР и LDAP-сервером по-разному.

Пример

1) Создать в БД LDAP-сервера пользователя, которому необходимо предоставить доступ к БД, например:
Имя:  GUEST
Пароль: qwerty123
2) Создать этого же пользователя в СУБД ЛИНТЕР вручную в режиме IDENTIFIED BY LDAP, например:
create or replace user GUEST identified by ldap;
3) Для доступа к БД указывать имя и пароль пользователя:
inl –u GUEST/”qwerty123”

Общие правила аутентификации с помощью Kerberos-сервера

Конструкция устанавливает для пользователя режим идентификации и аутентификации через Kerberos-сервер. Для входа под данным пользователем необходимо указывать пустые имя и пароль пользователя и/или задать специальный флаг в команде соединения с СУБД ЛИНТЕР в интерфейсе нижнего уровня.
Для идентификации и аутентификации по Kerberos-протоколу требуется, чтобы ядро СУБД ЛИНТЕР и «Центр распространения ключей» (KDC) Kerberos-сервера находились в ОС одного типа (либо семейства Windows, либо семейства UNIX-подобных).

Пример

1) Ядро СУБД ЛИНТЕР должно быть запущено с аргументом
    /KRBSRVC=< адрес Kerberos-сервиса >
2) Создать в БД Kerberos-сервера пользователя с некими учетными данными, например:
Имя:  GUEST
Пароль: qwerty123
3) Создать этого же пользователя в СУБД ЛИНТЕР вручную с использованием конструкции IDENTIFIED BY KRB, например:
create or replace user GUEST identified by KRB;
4) Для доступа к БД имя и пароль пользователя не указывать:
  а)
inl –u /
  б)
inl < Enter >
Имя пользователя   : < Enter >
Пароль пользователя: < Enter >
SQL >
  в) утилита «Рабочий стол СУБД ЛИНТЕР»:
В SQL-редакторе
username SYSTEM/MANAGER8
select count(*) from auto;
select count(*) from GUEST.auto; // ошибка – нет доступа

! на компьютере (в ОС) работает пользователь GUEST
username /
select count(*) from GUEST.auto; // ОК

Общие правила предоставления уровней доступа и доверия

Назначаемые < идентификаторами > уровень доступа < RAL > и уровень доверия < WAL > (см. документ «СУБД ЛИНТЕР. Администрирование комплекса средств защиты данных», подпункт «Метка субъекта») должны быть определены в системной таблице $$$LEVEL.
Если < RAL > и < WAL > не заданы, по умолчанию назначаются пустые метки доступа (это означает, что такой пользователь не будет иметь доступ ни к каким защищаемым метками доступа объектам БД).

Пример

select * from $$$level;
$$$ID      $$$NAME          $$$DESCR
1          НЕСЕКРЕТНО
2          ДСП
3          СЕКРЕТНО
4          Сов. секретно

create or replace user GUEST identified by '12345678'
level ("Сов. секретно", "СЕКРЕТНО");

Общие правила включения в группу пользователей

< Имя группы > должно быть определено до добавления в нее пользователя.
< Имя группы > задает принадлежность пользователя к указанной группе (с соответствующими этой группе правами доступа к объектам БД).

Пример

create user usr1 identified by '12345678';
create user "Гость" identified by '12345678';
create group "Администрация";
create if not exists group "Бухгалтерия"=20;
create group Marketing;
select $$$id, $$$name from $$$group;
$$$ID $$$NAME
1     Администрация
2     MARKETING
20    Бухгалтерия

create or replace user GUEST identified by '12345678' group "Администрация";
create or replace user USER2 identified by '12345678' group Marketing;