Как использовать роли и управлять разрешениями в PostgreSQL на VPS

Что такое PostgreSQL

PostgreSQL — это система управления базами данных с открытым исходным кодом, которая использует язык запросов SQL. PostgreSQL — это мощный инструмент, который можно использовать для управления приложениями и веб-данными на вашем VPS.

В этом gude мы обсудим, как правильно управлять привилегиями и разрешениями доступа пользователей. Это позволит вам предоставлять приложениям необходимые им привилегии, не позволяя им свободно влиять на отдельные базы данных.

Мы будем использовать PostgreSQL на облачном сервере Ubuntu 12.04, но все, кроме установки, должно работать одинаково в любом современном дистрибутиве Linux.

Начальная настройка PostgreSQL

Если у вас еще нет PostgreSQL на Ubuntu, введите следующие команды для его загрузки и установки:

Обновление sudo apt-get
sudo apt-get install postgresql postgresql-contrib

Во время установки PostgreSQL создаст пользователя по умолчанию для работы. Мы будем использовать этого пользователя для начальных шагов. Войдите в систему со следующей командой:

sudo su - postgres

Теперь наша среда подготовлена, и мы можем начать изучать, как PostgreSQL обрабатывает разрешения.

Концепции разрешения PostgreSQL

PostgreSQL (или просто «postgres») управляет разрешениями через понятие «роли».

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

Например, роли могут быть членами других ролей, позволяя им использовать характеристики разрешения ранее определенных ролей. Роли также могут владеть объектами и контролировать доступ к этим объектам для других ролей.

Как просматривать роли в PostgreSQL

Мы можем просмотреть текущие определенные роли в PostgreSQL, войдя в интерфейс приглашения с помощью следующей команды:

PSQL

Чтобы получить список ролей, введите следующее:

\du
                           List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication | {}

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

Как создать роли в PostgreSQL

Существует несколько способов создания ролей для Postgres. Можно создавать роли из Postgres или из командной строки.

Как создать роли изнутри PostgreSQL

Самый простой способ создания новых ролей — из командной строки Postgres.

Вы можете создать новую роль со следующим синтаксисом:

CREATE ROLE new_role_name;

Давайте создадим новую роль под названием «demo_role»:

CREATE ROLE demo_role;
CREATE ROLE

Если мы снова проверим определенных пользователей, мы получим следующее:

\du
                         List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 demo_role | Cannot login                                   | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}

Единственная информация, которую мы даем, заключается в том, что новая роль не имеет привилегий входа. Сейчас все в порядке.

Как создать роли из командной строки

Альтернативный способ создания ролей — использовать команду createuser.

Выйдите из командной строки PostgreSQL, набрав:

\q

Создайте роль под названием «test_user» со следующей командой:

createuser test_user
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Вам будет задан ряд вопросов, которые будут определять некоторые начальные разрешения для новой роли. Если вы ответите «n» на отсутствие всех этих запросов, вы создадите пользователя, аналогичного предыдущему пользователю, который мы создали.

Мы можем вернуться в приглашение Postgres и снова выпустить команду «\ du», чтобы увидеть различия между двумя новыми ролями:

PSQL
\du
                     List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 demo_role | Cannot login                                   | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}
 test_user |                                                | {}

Как вы можете видеть, эти команды не дают одинаковых результатов. Пользователь, созданный из командной строки, не имеет «Невозможно войти», указанного в качестве атрибута.

Как удалить роли в PostgreSQL

В качестве упражнения попробуем получить «demo_role», чтобы иметь те же права, что и «test_user». Сначала мы попытаемся сделать это во время создания, а затем научимся изменять разрешения существующей роли.

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

Вы можете удалить роль, используя следующий синтаксис:

DROP ROLE role_name;

Удалите роль «demo_role», набрав:

DROP ROLE demo_role;
DROP ROLE

Если мы выдаем команду несуществующему пользователю, мы получим эту ошибку:

DROP ROLE demo_role;
ERROR:  role "demo_role" does not exist

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

DROP ROLE IF EXISTS role_name;

Как вы можете видеть, с указанной опцией команда будет успешно завершена независимо от действительности роли:

DROP ROLE IF EXISTS demo_role;
NOTICE:  role "demo_role" does not exist, skipping
DROP ROLE

Как определить привилегии при создании ролей

Теперь мы готовы воссоздать роль demo_role с измененными разрешениями. Мы можем сделать это, указав необходимые разрешения после основного предложения create:

CREATE ROLE role_name WITH optional_permissions;

Вы можете увидеть полный список параметров, набрав:

\h CREATE ROLE

Мы хотим предоставить этому пользователю возможность входа в систему, поэтому мы наберем:

CREATE ROLE demo_role WITH LOGIN;
CREATE ROLE

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

\ их
        List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 demo_role |                                                | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}
 test_user |                                                | {}

Если мы хотим перейти в это состояние без указания атрибута «login» при каждом создании роли, мы можем использовать следующую команду вместо команды «CREATE ROLE»:

CREATE USER role_name;

Единственная разница между этими двумя командами заключается в том, что «CREATE USER» автоматически предоставляет привилегии доступа к роли.

Как изменить привилегии ролей в PostgreSQL

Чтобы изменить атрибуты уже созданной роли, мы используем команду «ALTER ROLE».

Эта команда позволяет нам определять изменения привилегий, не удаляя и воссоздавая пользователей, как мы показали ранее.

Основной синтаксис:

ALTER ROLE role_name WITH attribute_options

Например, мы можем изменить «demo_role» на прежнее состояние, выпустив эту команду:

ALTER ROLE demo_role WITH NOLOGIN;
ALTER ROLE

Мы можем видеть, что привилегии вернулись к прежнему состоянию:

\du
 List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 demo_role | Cannot login                                   | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}
 test_user |                                                | {}

Мы можем легко изменить его с помощью следующей команды:

ALTER ROLE demo_role WITH LOGIN;

Как войти в качестве другого пользователя в PostgreSQL

По умолчанию пользователям разрешен вход в систему только в том случае, если имя пользователя системы соответствует имени пользователя PostgreSQL.

Мы можем обойти это, изменив тип входа или указав, что PostgreSQL должен использовать сетевой интерфейс loopback, который изменит тип соединения на удаленный, хотя это фактически локальное соединение.

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

Дайте «test_user» пароль с помощью следующей команды:

\ password test_user

Вам будет предложено ввести и подтвердить пароль. Теперь выйдите из интерфейса PostgreSQL и вернитесь к своему обычным пользователям.

\q
exit

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

Это не относится к ситуации, которую мы демонстрируем, поэтому нам нужно будет явно указать параметры, которые мы хотим использовать. Используйте следующий синтаксис:

PSQL -U user_name -d database_name -h 127.0.0.1 -W

«User_name» следует заменить на имя пользователя, с которым мы хотим установить соединение. Точно так же имя базы данных должно быть именем существующей базы данных, к которой у вас есть доступ.

Раздел «-h 127.0.0.1» — это часть, которая указывает, что мы будем подключаться к локальной машине, но через сетевой интерфейс, который позволяет нам проходить аутентификацию, даже если наше системное имя пользователя не совпадает. Флаг «-W» сообщает PostgreSQL, что мы будем вводить пароль.

Чтобы войти в систему с помощью нашего «test_user», мы можем выполнить следующую команду:

psql -U test_user -d postgres -h 127.0.0.1 -W
Password for user test_user:

Вам нужно будет ввести пароль, который вы сконфигурировали. В нашем примере мы используем базу данных «postgres». Это база данных по умолчанию, настроенная во время установки.

Если вы попытаетесь выполнить некоторые действия в этом сеансе, вы увидите, что у вас нет возможности делать много вещей. Это связано с тем, что мы не предоставляли разрешения «test_user» для администрирования многих вещей.

Вернемся к административной сессии:

\q
sudo su - postgres
psql

Как предоставить разрешения в PostgreSQL

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

Мы можем предоставить разрешения с помощью команды «GRANT». Общий синтаксис здесь:

GRANT permission_type ON table_name TO role_name;

Создайте простую таблицу, чтобы практиковать эти концепции:

CREATE TABLE демо (
имя varchar (25),
id serial,
start_date date);
NOTICE:  CREATE TABLE will create implicit sequence "demo_id_seq" for serial column "demo.id"
CREATE TABLE

Мы можем видеть результат:

\ d
     List of relations
 Schema |    Name     |   Type   |  Owner   
--------+-------------+----------+----------
 public | demo        | table    | postgres
 public | demo_id_seq | sequence | postgres
(2 rows)

Теперь мы можем предоставить некоторые привилегии новой таблице «demo» для «demo_role». Предоставьте пользователям привилегии «UPDATE» следующей командой:

GRANT UPDATE ON demo TO demo_role;

Мы можем предоставить полные разрешения пользователю, заменив тип разрешений словом «все»:

GRANT ALL ON demo TO test_user;

Если мы хотим указать разрешения для каждого пользователя в системе, мы можем использовать слово «public», а не конкретный пользователь:

GRANT INSERT ON demo TO PUBLIC;

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

\z
                      Access privileges
 Schema |    Name     |   Type   |     Access privileges      | Column access privileges 
--------+-------------+----------+----------------------------+--------------------------
 public | demo        | table    | postgres=arwdDxt/postgres +| 
        |             |          | demo_role=w/postgres      +| 
        |             |          | test_user=arwdDxt/postgres+| 
        |             |          | =a/postgres                | 
 public | demo_id_seq | sequence |                            | 
(2 rows)

Это отображает все предоставленные разрешения грантов.

Как удалить разрешения в PostgreSQL

Вы можете удалить разрешения с помощью команды «REVOKE». Команда отзыва использует почти тот же синтаксис, что и grant:

REVOKE permission_type ON table_name FROM user_name;

Опять же, мы можем использовать те же сокращенные слова (все и общедоступные), чтобы облегчить команду:

REVOKE INSERT ON demo FROM PUBLIC;

Как использовать роли группы в PostgreSQL

Роли достаточно гибкие, чтобы позволить группировать другие роли, чтобы обеспечить широкомасштабный контроль разрешений.

Например, мы можем создать новую роль под названием «tempor_users», а затем добавить к этой роли «demo_role» и «test_user»:

CREATE ROLE tempor_users;
GRANT tempor_users TO demo_role;
GRANT tempor_users TO test_user;

Теперь эти два пользователя могут управлять своими правами, управляя ролью группы «временные_узлы» вместо управления каждым членом отдельно.

Мы можем видеть информацию о членстве в роли, набрав:

\du
   List of roles
    Role name    |                   Attributes                   |     Member of     
-----------------+------------------------------------------------+-------------------
 demo_role       |                                                | {temporary_users}
 postgres        | Superuser, Create role, Create DB, Replication | {}
 temporary_users | Cannot login                                   | {}
 test_user       |                                                | {temporary_users}

Любой член групповой роли может выступать в роли группы, членом которой они являются, используя команду «set role».

Поскольку пользователь «postgres», с которым мы вошли в настоящее время, имеет привилегии суперпользователя, мы можем использовать «заданную роль», даже если мы не являемся членами этой группы:

SET ROLE tempor_users;

Теперь любые созданные таблицы принадлежат роли временные_узлы:

CREATE TABLE hello (
name varchar(25),
id serial,
start_date date);

Мы можем проверить право собственности на таблицу, выполнив следующую команду:

\ d
             List of relations
 Schema |     Name     |   Type   |      Owner      
--------+--------------+----------+-----------------
 public | demo         | table    | postgres
 public | demo_id_seq  | sequence | postgres
 public | hello        | table    | temporary_users
 public | hello_id_seq | sequence | temporary_users
(4 rows)

Как вы можете видеть, новая таблица (и последовательность, связанная с типом последовательных данных) принадлежит роли «временные_субы».

Мы можем вернуться к нашим исходным разрешениям с помощью следующей команды:

RESET ROLE;

Если мы предоставим пользователю свойство «inherit» с командой «alter role», этот пользователь будет автоматически иметь все привилегии принадлежащих им ролей, не используя команду «set role»:

ALTER ROLE test_user INHERIT;

Теперь у test_user будут все разрешения ролей, в которые он входит.

Мы можем удалить роль группы (или любую роль) с помощью команды «drop role»:

DROP ROLE tempor_users;
ERROR:  role "temporary_users" cannot be dropped because some objects depend on it
DETAIL:  owner of table hello
owner of sequence hello_id_seq

Это даст вам ошибку, потому что мы создали таблицу, принадлежащую «tempor_users». Мы можем решить эту проблему, передав право собственности на другую роль:

ALTER TABLE hello OWNER TO demo_role;

Если мы проверим, мы увидим, что «tempor_users» больше не владеет ни одной из таблиц:

\ d
            List of relations
 Schema |     Name     |   Type   |   Owner   
--------+--------------+----------+-----------
 public | demo         | table    | postgres
 public | demo_id_seq  | sequence | postgres
 public | hello        | table    | demo_role
 public | hello_id_seq | sequence | demo_role
(4 rows)

Теперь мы можем успешно удалить роль «временные_субы», снова выпустив команду:

DROP ROLE tempor_users;

Это уничтожит роль tempor_users. Бывшие члены временного пользователя не удаляются.

Заключение

Теперь у вас должны быть базовые навыки, необходимые для администрирования ваших разрешений базы данных PostgreSQL. Важно знать, как управлять разрешениями, чтобы ваши приложения могли обращаться к необходимым им базам данных, не прерывая данные, используемые другими приложениями.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *