Доступные версии документации

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

Функция

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

Спецификация
   
<создание пользователя>::=
CREATE [IF NOT EXISTS |OR REPLACE] USER имя пользователя
[IDENTIFIED BY {пароль |SYSTEM|PROTOCOL|LDAP|KRB}]
[LEVEL (RAL, WAL)]
[GROUP имя группы]
Общие для всех механизмов аутентификации синтаксические правила
  1. Опция OR REPLACE заставляет в случае, если пользователь существует в БД, удалять и пересоздавать его под тем же именем, но с указанными параметрами.

  2. Опция IF NOT EXISTS отменяет выполнение оператора, если указанный пользователь уже существует в БД.

  3. Для создания нового пользователя необходимо иметь уровень прав DBA.

  4. <Имя пользователя> должно быть уникальным среди имен пользователей, схем и ролей БД.

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

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

  6. В процессе авторизации пользователю, созданному командой CREATE USER и прошедшему аутентификацию, присваивается CONNECT-категория (т.е. доступ к БД с возможностью подавать SQL-запросы на манипулирование данными с теми объектами БД, владельцы которых предоставили ему такое право).

Примеры

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

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

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

create user "guest";
create user guest;
Синтаксические правила парольной аутентификации
  1. <Пароль> не должен превышать 18 символов.

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

    Пример

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

    create or replace user guest identified by 'qwerty123';
    create or replace user guest identified by 'Qwerty123';
Общие правила парольной аутентификации
  1. Восстановить утерянный <пароль> невозможно.

Примеры

1)

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

2)

create user "Гость" identified by 'без пароля';
username "Гость"/"без пароля"
Общие правила аутентификации средствами ОС
  1. Создание пользователя с аутентификацией средствами ОС (встроенная в ОС аутентификация) возможно только в операционных системах, которые поддерживают эту функциональность (семейство Windows NT, SunOS, FreeBSD, Linux). В этом случае в ОС должна быть учётная запись пользователя с таким именем.

  2. В ОС Windows NT пользователь ОС, для которого в базе данных устанавливается режим аутентификации средствами ОС, должен иметь привилегию SE_TCB_NAME («Act as part of the Operating System» – «Работа в режиме операционной системы»).

  3. Конструкция устанавливает для пользователя режим встроенной аутентификации операционной системы. Это означает, что при доступе к БД надо указывать имя, идентичное имени при регистрации в ОС, и пустой пароль. СУБД ЛИНТЕР выполняет только идентификацию пользователя с указанным именем и дает ему и разрешение на доступ к БД, а аутентификацию выполняет ОС.

  4. В UNIX-системах создание пользователя со встроенной аутентификацией выполняется с помощью разделяемой библиотеки PAM (Pluggable Authentication Modules – подключаемые модули аутентификации). Вследствие этого пользователь ОС, от имени которого запускается ядро СУБД ЛИНТЕР, должен иметь доступ на чтение паролей ОС.

Пример
create or replace user "Sakharov" identified by system;
username "Sakharov"/
Общие правила аутентификации BY PROTOCOL
  1. Конструкция задает идентификацию и аутентификацию пользователя при проверке доступа к БД по имени пользователя, зарегистрированного в ОС.

  2. При запуске клиентских приложений, выполняющих соединение с СУБД ЛИНТЕР, имя пользователя надо задавать пустым (пароль в этом случае запрашиваться не будет).

    create or replace user "Sakharov" identified by protocol;
    inl –u /

    или

    inl <Enter>
    Имя пользователя   : <Enter>
    Пароль пользователя: <Enter>
    SQL>
  3. Пользователь-владелец БД не может идентифицироваться и аутентифицироваться таким способом.

  4. Доступ к БД будет проверяться от имени текущего пользователя ОС.

Примечание

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

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

  2. При создании пароля на LDAP-сервере необходимо избегать паролей с конечными пробелами, поскольку они интерпретируются СУБД ЛИНТЕР и LDAP-сервером по-разному.

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

  2. Для идентификации и аутентификации по 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/MANAGER
select count(*) from auto;
select count(*) from GUEST.auto; // ошибка – нет доступа

! на компьютере (в ОС) работает пользователь GUEST
username /
select count(*) from GUEST.auto; // ОК
Общие правила предоставления уровней доступа и доверия
  1. Назначаемые <идентификаторами> уровень доступа <RAL> и уровень доверия <WAL> должны быть определены в системной таблице $$$LEVEL (см. документ «СУБД ЛИНТЕР. Администрирование комплекса средств защиты данных»).

  2. Если <RAL> и <WAL> не заданы, по умолчанию назначаются пустые метки доступа (это означает, что такой пользователь не будет иметь доступ ни к каким защищаемым метками доступа объектам БД).

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

create or replace user GUEST identified by '12345'
level ("Сов. секретно", "СЕКРЕТНО");
Общие правила включения в группу пользователей
  1. <Имя группы> должно быть определено до добавления в нее пользователя.

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

Пример
create user usr1;
create user "Гость" identified by 'guest';
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 group "Администрация";
create or replace user USER2 group Marketing;
Заметили ошибку?
Выделите текст и нажмите Ctrl + Enter