Owner to postgresql что это
Перейти к содержимому

Owner to postgresql что это

  • автор:

Сахар для слоненка — быстрый старт c PostgreSQL для команд в НЛМК

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

В процессе общения с различными командами в НЛМК у меня появилась идея предложить им «преднастроенный PostgreSQL». Как в итоге сделали — под катом.

Сахар для слоненка

Ролевая модель

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

Поэтому мы попробовали собрать требования к ролевой модели:

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

Итого, разделяя объекты по схемам, у нас есть роль на чтение всех объектов в ней и на запись. Максимально просто.

Шаблон имен наших ролей имеет вид:

  • prefix — префикс для ролей (опционально);
  • db_name — имя базы данных;
  • schema_name — имя схемы, для которой создана роль;
  • role_name — имя роли.

Рассмотрим необходимые нам роли (role_name из шаблона выше):

  • owner — владелец схемы. Роль типа NOLOGON. Эта роль непосредственно никому не присваивается, а передается через sudo роль (ниже будет пример);
  • sudo — роль типа NOLOGON и NOINHERIT (роль не наследует права ролей, членом которых она является), ей присвоена роль owner. Переключение на роль owner выполняется через SET ROLE;
  • view — роль типа NOLOGON, через которую предоставляется доступ только на чтение к сущностям в схеме;
  • write — роль типа NOLOGON, через нее предоставляется доступ только на запись к сущностям в схеме;
  • pgm — роль типа NOLOGON для инструмента миграции схем.

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

Возможно, вам придется расширить права для ролей или как-то адаптировать их под себя.

Зачем нужна отдельная sudo роль и owner?

В PostgreSQL есть функционал, который позволяет задать права по умолчанию для создаваемых объектов — DEFAULT PRIVILEGES , но объекты должны быть созданы именно из под этой роли. Мы задаем DEFAULT PRIVILEGES для роли owner. Перед тем, как что‑то создать, необходимо явно сделать set role *_owner .

Если мы просто добавим пользователя в эту роль, то он сможет создавать объекты во всех схемах и есть риск, что может забыть сделать set role .

Чтобы решить эту проблему, мы сделали отдельную роль _sudo со свойством NOINHERIT , которая является членом роли owner, и пользователь вынужден всегда делать set role явно, чтобы получить нужные права.

Миграция схем

После создания схем и базовых ролей, следующим важным компонентом является инструмент миграции. Наш выбор пал на PGmigrate от Yandex. Он прост, позволяет использовать нашу ролевую модель и подход gitops.

В git для проекта мы создаем следующую структуру:

/ / migrations.yml / / 00_after_each.sql / 00_before_each.sql . 

Для генерации структуры можно воспользоваться скриптом из того же репозитория в github.

В файле migrations.yml мы указываем запросы, которые будут выполнены до и после каждой версии миграции.

callbacks:
beforeEach:
— callbacks/beforeEach
afterEach:
— callbacks/afterEach
conn: dbname=$
schema: $

00_before_each.sql , делаем SET ROLE на владельца схемы и устанавливаем search_path в имя схемы.

SET ROLE $$_$_owner;
SET search_path = ‘$’;

В 00_after_each.sql , сбрасываем роль и search_path .

RESET ROLE;
SET search_path TO DEFAULT ;

Пример такой структуры можно посмотреть в директории migrations на github.

Мы используем немного измененный скрипт PGmigrate, но создали issue и надеемся скоро опять использовать официальный.

Пример запуска примера из репозитория с github

# Запускаем postgres и pgadmin $ docker-compose up -d postgres pgadmin # Создаем новую базу данных с именем dwh $ docker-compose exec -u postgres postgres psql -c 'CREATE DATABASE dwh' CREATE DATABASE # Создаем схемы и ролевую модель $ docker-compose exec -u postgres postgres /bin/bash /opt/scripts/create_schema.sh Schema: dwh_raw GRANT dwh_raw_view,dwh_raw_write TO dwh_raw_owner GRANT dwh_raw_view TO dwh_raw_sudo GRANT dwh_raw_owner TO dwh_raw_sudo GRANT CONNECT ON DATABASE dwh TO dwh_raw_view GRANT dwh_raw_view TO dwh_raw_write GRANT usage ON SCHEMA raw TO dwh_raw_view GRANT ALL ON SCHEMA raw TO dwh_raw_owner GRANT ALL ON SCHEMA raw TO dwh_raw_pgm GRANT dwh_raw_sudo TO dwh_raw_pgm ALTER DEFAULT PRIVILEGES FOR ROLE dwh_raw_owner IN SCHEMA raw GRANT SELECT ON SEQUENCES TO dwh_raw_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_raw_owner IN SCHEMA raw GRANT SELECT ON TABLES TO dwh_raw_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_raw_owner IN SCHEMA raw GRANT ALL ON SEQUENCES TO dwh_raw_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_raw_owner IN SCHEMA raw GRANT EXECUTE ON FUNCTIONS TO dwh_raw_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_raw_owner IN SCHEMA raw GRANT INSERT,UPDATE,DELETE,TRUNCATE ON TABLES TO dwh_raw_write Schema: dwh_ods GRANT dwh_ods_view,dwh_ods_write TO dwh_ods_owner GRANT dwh_ods_view TO dwh_ods_sudo GRANT dwh_ods_owner TO dwh_ods_sudo GRANT CONNECT ON DATABASE dwh TO dwh_ods_view GRANT dwh_ods_view TO dwh_ods_write GRANT usage ON SCHEMA ods TO dwh_ods_view GRANT ALL ON SCHEMA ods TO dwh_ods_owner GRANT ALL ON SCHEMA ods TO dwh_ods_pgm GRANT dwh_ods_sudo TO dwh_ods_pgm ALTER DEFAULT PRIVILEGES FOR ROLE dwh_ods_owner IN SCHEMA ods GRANT SELECT ON SEQUENCES TO dwh_ods_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_ods_owner IN SCHEMA ods GRANT SELECT ON TABLES TO dwh_ods_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_ods_owner IN SCHEMA ods GRANT ALL ON SEQUENCES TO dwh_ods_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_ods_owner IN SCHEMA ods GRANT EXECUTE ON FUNCTIONS TO dwh_ods_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_ods_owner IN SCHEMA ods GRANT INSERT,UPDATE,DELETE,TRUNCATE ON TABLES TO dwh_ods_write Schema: dwh_cdm GRANT dwh_cdm_view,dwh_cdm_write TO dwh_cdm_owner GRANT dwh_cdm_view TO dwh_cdm_sudo GRANT dwh_cdm_owner TO dwh_cdm_sudo GRANT CONNECT ON DATABASE dwh TO dwh_cdm_view GRANT dwh_cdm_view TO dwh_cdm_write GRANT usage ON SCHEMA cdm TO dwh_cdm_view GRANT ALL ON SCHEMA cdm TO dwh_cdm_owner GRANT ALL ON SCHEMA cdm TO dwh_cdm_pgm GRANT dwh_cdm_sudo TO dwh_cdm_pgm ALTER DEFAULT PRIVILEGES FOR ROLE dwh_cdm_owner IN SCHEMA cdm GRANT SELECT ON SEQUENCES TO dwh_cdm_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_cdm_owner IN SCHEMA cdm GRANT SELECT ON TABLES TO dwh_cdm_view ALTER DEFAULT PRIVILEGES FOR ROLE dwh_cdm_owner IN SCHEMA cdm GRANT ALL ON SEQUENCES TO dwh_cdm_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_cdm_owner IN SCHEMA cdm GRANT EXECUTE ON FUNCTIONS TO dwh_cdm_write ALTER DEFAULT PRIVILEGES FOR ROLE dwh_cdm_owner IN SCHEMA cdm GRANT INSERT,UPDATE,DELETE,TRUNCATE ON TABLES TO dwh_cdm_write # Создаем пользователя для выполнения миграций и добавляем в _pgm группы схем $ docker-compose exec -u postgres postgres psql -c "create user pgmigrate with password '1234' in group dwh_raw_pgm,dwh_ods_pgm,dwh_cdm_pgm;" CREATE ROLE # Выполняем миграции $ docker-compose run pgmigrate bash /opt/scripts/do_migrate.sh + pgmigrate -d /opt/migrations/dwh/raw -v -m raw --check_serial_versions -t latest migrate + pgmigrate -d /opt/migrations/dwh/ods -v -m ods --check_serial_versions -t latest migrate + pgmigrate -d /opt/migrations/dwh/cdm -v -m cdm --check_serial_versions -t latest migrate # Подключаемся к базе dwh с помощью psql $ docker-compose exec -u postgres postgres psql -d dwh # Наши созданные скриптом create_schema.sh схемы dwh=# \dn List of schemas Name | Owner --------+------------------- cdm | postgres ods | postgres public | pg_database_owner raw | postgres (4 rows) # Таблица foo создана pgmigrate c владельцем dwh_raw_owner # Таблица schema_version - техническая для pgmigrate, без Access privileges dwh=# \dt raw.* List of relations Schema | Name | Type | Owner --------+----------------+-------+--------------- raw | foo | table | dwh_raw_owner raw | schema_version | table | pgmigrate dwh=# \dp raw.* Access privileges Schema | Name | Type | Access privileges | Column privileges | Policies --------+----------------+-------+-------------------------------------+-------------------+---------- raw | foo | table | dwh_raw_view=r/dwh_raw_owner +| | | | | dwh_raw_write=awdD/dwh_raw_owner +| | | | | dwh_raw_owner=arwdDxt/dwh_raw_owner | | raw | schema_version | table | | (2 rows)

Проверки в CI

Перед миграцией в master мы выполняем следующие проверки:

  • не изменены файлы уже примененных версий миграций;
  • в скритах миграций нет set role или reset role;
  • имя файла в миграции соответствует требованиям PGmigrate: V__.sql;
  • версии в миграциях последовательно возрастают (pgmigrate умеет это проверять);
  • изменяется только одна схема в директории со схемой (pgmigrate умеет это проверять, но непосредственно в момент применения миграций);
  • наличие в скрипте миграции первой строкой указания использовать utf-8( /* pgmigrate-encoding: utf-8 */ ), чтобы избежать проблем с non‑ascii символами;
  • применение всех миграций в CI на временной БД для проверки на наличие ошибок в SQL коде.

После чего для каждой схемы, где были изменения, выполняем миграции с помощью команды:
pgmigrate.py -d / -v -m —check_serial_versions -t latest migrate

Пользователи и группы

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

На каждую роль *_view , *_write и *_sudo создается своя группа в AD. Периодически скриптом мы синхронизируем членов этой группы с соответствующими группами в PostgreSQL, создаем отсутствующих пользователей. Наш скрипт умеет работать со вложенными группами, и это позволяет в качестве членов групп использовать другие группы в AD, например группа «все разработчики BI».

Полезно также иметь общую группу в AD на каждый сервер, включающую все эти группы, чтобы в pg_hba.conf или в PGAdmin дополнительно ограничить доступ с помощью ldapsearchfilter:

Пример из pg_hba.conf:

# Все пользователи группы g-dbx-users, в том числе и во вложенных группах

host all all 0.0.0.0/0 ldap ldapserver=ldap.expample ldapsearchfilter=»(&(samAccountName=$username)(memberof:1.2.840.113556.1.4.1941:=CN=g-dbx-users,OU=pg. ))»

Реальный пример

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

Его архитектура представлена ниже:

В базе данных созданы три схемы (слоя): raw, ods, cdm. На каждую схему в PostgreSQL созданы 4 роли(+1 для миграций — pgm).

В LDAP на каждую схему создано три группы, соответствующие *_view, *_write и *_sudo.

Код миграций лежит в GIT. Миграции выполняются под доменным пользователем dbx‑pgmigrate , который входит в локальные группы dbx_raw_pgm , dbx_ods_pgm , dbx_cdm_pgm в PostgreSQL.

Перекладка данных между схемами/слоями осуществляется сервисом Airflow, который подключается к БД под пользователем dbx‑airflow и имеет только write права на схемы.

Также на схеме присутствует BI сервис, который подключается к PostgreSQL под пользователем bi‑user и имеет права только на чтение в схему CDM. И сервис PGAdmin, через который пользователь dbx‑dev‑user1 может подключаться к PostgreSQL и выполнять запросы на чтение во всех трех схемах.

Итого

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

Надеюсь, предложенный подход вам будет полезен!

Owner to postgresql что это

ALTER DATABASE — change a database

Synopsis

ALTER DATABASE name [ [ WITH ] option [ . ] ] where option can be: ALLOW_CONNECTIONS allowconn CONNECTION LIMIT connlimit IS_TEMPLATE istemplate ALTER DATABASE name RENAME TO new_name ALTER DATABASE name OWNER TO < new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER > ALTER DATABASE name SET TABLESPACE new_tablespace ALTER DATABASE name REFRESH COLLATION VERSION ALTER DATABASE name SET configuration_parameter < TO | = >< value | DEFAULT > ALTER DATABASE name SET configuration_parameter FROM CURRENT ALTER DATABASE name RESET configuration_parameter ALTER DATABASE name RESET ALL

Description

ALTER DATABASE changes the attributes of a database.

The first form changes certain per-database settings. (See below for details.) Only the database owner or a superuser can change these settings.

The second form changes the name of the database. Only the database owner or a superuser can rename a database; non-superuser owners must also have the CREATEDB privilege. The current database cannot be renamed. (Connect to a different database if you need to do that.)

The third form changes the owner of the database. To alter the owner, you must be able to SET ROLE to the new owning role, and you must have the CREATEDB privilege. (Note that superusers have all these privileges automatically.)

The fourth form changes the default tablespace of the database. Only the database owner or a superuser can do this; you must also have create privilege for the new tablespace. This command physically moves any tables or indexes in the database’s old default tablespace to the new tablespace. The new default tablespace must be empty for this database, and no one can be connected to the database. Tables and indexes in non-default tablespaces are unaffected.

The remaining forms change the session default for a run-time configuration variable for a PostgreSQL database. Whenever a new session is subsequently started in that database, the specified value becomes the session default value. The database-specific default overrides whatever setting is present in postgresql.conf or has been received from the postgres command line. Only the database owner or a superuser can change the session defaults for a database. Certain variables cannot be set this way, or can only be set by a superuser.

Parameters

The name of the database whose attributes are to be altered.

If false then no one can connect to this database.

How many concurrent connections can be made to this database. -1 means no limit.

If true, then this database can be cloned by any user with CREATEDB privileges; if false, then only superusers or the owner of the database can clone it.

The new name of the database.

The new owner of the database.

The new default tablespace of the database.

This form of the command cannot be executed inside a transaction block.

REFRESH COLLATION VERSION

Update the database collation version. See Notes for background.

Set this database’s session default for the specified configuration parameter to the given value. If value is DEFAULT or, equivalently, RESET is used, the database-specific setting is removed, so the system-wide default setting will be inherited in new sessions. Use RESET ALL to clear all database-specific settings. SET FROM CURRENT saves the session’s current value of the parameter as the database-specific value.

See SET and Chapter 20 for more information about allowed parameter names and values.

Notes

It is also possible to tie a session default to a specific role rather than to a database; see ALTER ROLE . Role-specific settings override database-specific ones if there is a conflict.

Examples

To disable index scans by default in the database test :

ALTER DATABASE test SET enable_indexscan TO off;

Compatibility

The ALTER DATABASE statement is a PostgreSQL extension.

See Also

Prev Up Next
ALTER CONVERSION Home ALTER DEFAULT PRIVILEGES

Submit correction

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.

Copyright © 1996-2023 The PostgreSQL Global Development Group

What is a PostgreSQL table owner?

The owner is (if nothing else happened) the user (role) that created the table. So if user arthur runs CREATE TABLE foo (id INTEGER) , arthur owns the table.

The owner of a table has all privileges on it — including the privilege to drop it. Or the privilege to grant other users (roles) access to the table.

The SQL script generated by pg_dump typically includes the ALTER TABLE . OWNER TO . statement as those scripts are intended to be run by the DBA and in that case all tables would be owned by the DBA — which means the «real» owner could not change or access the tables.

10.1k 10 10 gold badges 74 74 silver badges 97 97 bronze badges
answered Nov 21, 2015 at 9:32
user330315 user330315

Thanks so much! Just one thing: in the previous example can user ‘arthur’ grant privileges on table ‘foo’ to other roles?

Nov 21, 2015 at 9:35
@JonathanGinsburg: yes of course. The owner can do pretty much everything.
– user330315
Nov 21, 2015 at 9:37

Are there special privileges that an owner has that other users do not have? Can ownership be replicated by giving another user privilages?

Jan 31, 2022 at 16:35

Some excerpts from the official docs:

When an object is created, it is assigned an owner. The owner is normally the role that executed the creation statement. For most kinds of objects, the initial state is that only the owner (or a superuser) can do anything with the object. To allow other roles to use it, privileges must be granted.

The right to modify or destroy an object is inherent in being the object’s owner, and cannot be granted or revoked in itself. (However, like all privileges, that right can be inherited by members of the owning role; see Section 21.3.)

Ordinarily, only the object’s owner (or a superuser) can grant or revoke privileges on an object.

An object’s owner can choose to revoke their own ordinary privileges, for example to make a table read-only for themselves as well as others. But owners are always treated as holding all grant options, so they can always re-grant their own privileges.

Owner to postgresql что это

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

Существует несколько типов прав: SELECT , INSERT , UPDATE , DELETE , TRUNCATE , REFERENCES , TRIGGER , CREATE , CONNECT , TEMPORARY , EXECUTE и USAGE . Набор прав, применимых к определённому объекту, зависит от типа объекта (таблица, функция и т. д.). Более подробно назначение этих прав описывается ниже. Как применяются эти права, вы также увидите в следующих разделах и главах.

Неотъемлемое право изменять или удалять объект имеет только владелец объекта.

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

ALTER TABLE имя_таблицы OWNER TO новый_владелец;

Суперпользователь может делать это без ограничений, а обычный пользователь — только если он является одновременно текущим владельцем объекта (или членом роли владельца) и членом новой роли.

Для назначения прав применяется команда GRANT . Например, если в базе данных есть роль joe и таблица accounts , право на изменение таблицы можно дать этой роли так:

GRANT UPDATE ON accounts TO joe;

Если вместо конкретного права написать ALL , роль получит все права, применимые для объекта этого типа.

Для назначения права всем ролям в системе можно использовать специальное имя « роли » : PUBLIC . Также для упрощения управления ролями, когда в базе данных есть множество пользователей, можно настроить « групповые » роли; подробнее об этом см. Главу 20.

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

REVOKE ALL ON accounts FROM PUBLIC;

Особые права владельца объекта (то есть права на выполнение DROP , GRANT , REVOKE и т. д.) всегда неявно закреплены за владельцем и их нельзя назначить или отобрать. Но владелец объекта может лишить себя обычных прав, например, разрешить всем, включая себя, только чтение таблицы.

Обычно распоряжаться правами может только владелец объекта (или суперпользователь). Однако возможно дать право доступа к объекту « с правом передачи » , что позволит получившему такое право назначать его другим. Если такое право передачи впоследствии будет отозвано, то все, кто получил данное право доступа (непосредственно или по цепочке передачи), потеряют его. Подробнее об этом см. справку GRANT и REVOKE .

Все существующие права перечислены ниже:

Позволяет выполнять SELECT для любого столбца или перечисленных столбцов в заданной таблице, представлении, матпредставлении или другом объекте табличного вида. Также позволяет выполнять COPY TO. Помимо этого, данное право требуется для обращения к существующим значениям столбцов в UPDATE или DELETE . Для последовательностей это право позволяет пользоваться функцией currval . Для больших объектов оно позволяет читать содержимое объекта. INSERT

Позволяет вставлять с помощью INSERT строки в заданную таблицу, представление и т. п. Может назначаться для отдельных столбцов; в этом случае только этим столбцам можно присваивать значения в команде INSERT (другие столбцы получат значения по умолчанию). Также позволяет выполнять COPY FROM. UPDATE

Позволяет изменять с помощью UPDATE данные во всех, либо только перечисленных, столбцах в заданной таблице, представлении и т. п. (На практике для любой нетривиальной команды UPDATE потребуется и право SELECT , так как она должна обратиться к столбцам таблицы, чтобы определить, какие строки подлежат изменению, и/или вычислить новые значения столбцов.) Для SELECT . FOR UPDATE и SELECT . FOR SHARE также требуется иметь это право как минимум для одного столбца, помимо права SELECT . Для последовательностей это право позволяет пользоваться функциями nextval и setval . Для больших объектов это право позволяет записывать данные в объект или обрезать его. DELETE

Позволяет удалять с помощью DELETE строки из таблицы, представления и т. п. (На практике для любой нетривиальной команды DELETE потребуется также право SELECT , так как она должна обратиться к колонкам таблицы, чтобы определить, какие строки подлежат удалению.) TRUNCATE

Позволяет опустошать таблицу с помощью TRUNCATE . REFERENCES

Позволяет создавать ограничение внешнего ключа, обращающееся к таблице или определённым столбцам таблицы. TRIGGER

Позволяет создавать триггер для таблицы, представления и т. п. CREATE

Для баз данных это право позволяет создавать в них схемы и публикации.

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

Для табличных пространств это право позволяет создавать таблицы, индексы и временные файлы в определённом табличном пространстве, а также создавать базы данных, для которых это пространство будет основным. (Учтите, что когда это право отзывается, существующие объекты остаются в прежнем расположении.) CONNECT

Позволяет подключаться к базе данных. Это право проверяется при установлении соединения (в дополнение к условиям, определённым в конфигурации pg_hba.conf ). TEMPORARY

Позволяет создавать временные таблицы в определённой базе данных. EXECUTE

Позволяет вызывать функцию или процедуру, в том числе использовать любые операторы, реализованные данной функцией. Это единственный тип прав, применимый к функциям и процедурам. USAGE

Для процедурных языков это право позволяет создавать функции на определённом языке. Это единственный тип прав, применимый к процедурным языкам.

Для схем это право даёт доступ к содержащимся в них объектам (предполагается, что при этом имеются права, необходимые для доступа к самим объектам). По сути это право позволяет субъекту « просматривать » объекты внутри схемы. Без этого разрешения имена объектов всё же можно будет узнать, например, обратившись к системным каталогам. Кроме того, если отозвать это право, в существующих сеансах могут оказаться операторы, для которых просмотр имён объектов был выполнен ранее, так что это право не позволяет абсолютно надёжно перекрыть доступ к объектам.

Для последовательностей это право позволяет использовать функции currval и nextval .

Для типов и доменов это право позволяет использовать заданный тип или домен при создании таблиц, функций или других объектов схемы. (Заметьте, что это право не ограничивает общее « использование » типа, например обращение к значениям типа в запросах. Без этого права нельзя только создавать объекты, зависящие от заданного типа. Основное предназначение этого права в том, чтобы ограничить круг пользователей, способных создавать зависимости от типа, которые могут впоследствии помешать владельцу типа изменить его.)

Для обёрток сторонних данных это право позволяет создавать использующие их определения сторонних серверов.

Для сторонних серверов это право позволяет создавать использующие их сторонние таблицы. Наделённые этим правом могут также создавать, модифицировать или удалять собственные сопоставления пользователей, связанные с определённым сервером.

Права, требующиеся для других команд, указаны на страницах справки этих команд.

Postgres Pro по умолчанию назначает роли PUBLIC права для некоторых типов объектов, когда эти объекты создаются. Для таблиц, столбцов, последовательностей, обёрток сторонних данных, сторонних серверов, больших объектов, схем и табличных пространств PUBLIC по умолчанию никаких прав не получает. Для других типов объектов PUBLIC получает следующие права по умолчанию: CONNECT и TEMPORARY (создание временных таблиц) для баз данных; EXECUTE — для функций и процедур; USAGE — для языков и типов данных (включая домены). Владелец объекта, конечно же, может отозвать (посредством REVOKE ) как явно назначенные права, так и права по умолчанию. (Для максимальной безопасности команду REVOKE нужно выполнять в транзакции, создающей объект; тогда не образуется окно, в котором другой пользователь сможет обратиться к объекту.) Кроме того, эти изначально назначаемые права по умолчанию можно переопределить, воспользовавшись командой ALTER DEFAULT PRIVILEGES .

В Таблице 5.1 показаны однобуквенные сокращения, которыми обозначаются эти права в списках ACL (Access Control List, Список контроля доступа). Вы увидите эти сокращения в выводе перечисленных ниже команд psql или в столбцах ACL в системных каталогах.

Таблица 5.1. Сокращённые обозначения прав в ACL

Право Сокращение Применимые типы объектов
SELECT r ( « read » , чтение) LARGE OBJECT , SEQUENCE , TABLE (и объекты, подобным таблицам), столбец таблицы
INSERT a ( « append » , добавление) TABLE , столбец таблицы
UPDATE w ( « write » , запись) LARGE OBJECT , SEQUENCE , TABLE , столбец таблицы
DELETE d TABLE
TRUNCATE D TABLE
REFERENCES x TABLE , столбец таблицы
TRIGGER t TABLE
CREATE C DATABASE , SCHEMA , TABLESPACE
CONNECT c DATABASE
TEMPORARY T DATABASE
EXECUTE X FUNCTION , PROCEDURE
USAGE U DOMAIN , FOREIGN DATA WRAPPER , FOREIGN SERVER , LANGUAGE , SCHEMA , SEQUENCE , TYPE

В Таблица 5.2 для каждого типа SQL-объекта показаны относящиеся к нему права, с использованием приведённых выше сокращений. Также в ней для каждого типа приведена команда psql , которая позволяет узнать, какие права назначены для объекта этого типа.

Таблица 5.2. Сводка прав доступа

Тип объекта Все права Права PUBLIC по умолчанию Команда psql
DATABASE CTc Tc \l
DOMAIN U U \dD+
FUNCTION или PROCEDURE X X \df+
FOREIGN DATA WRAPPER U нет \dew+
FOREIGN SERVER U нет \des+
LANGUAGE U U \dL+
LARGE OBJECT rw нет
SCHEMA UC нет \dn+
SEQUENCE rwU нет \dp
TABLE (и объекты, подобные таблицам) arwdDxt нет \dp
Столбец таблицы arwx нет \dp
TABLESPACE C нет \db+
TYPE U U \dT+

Права, назначенные для определённого объекта, выводятся в виде элементов aclitem , где каждый aclitem отражает разрешения, которые были предоставлены субъекту определённым праводателем. Например, запись calvin=r*w/hobbes означает, что роль calvin имеет право SELECT ( r ) с возможностью передачи ( * ), а также непередаваемое право UPDATE ( w ), и оба эти права даны ему ролью hobbes . Если calvin имеет для этого объекта и другие права, предоставленные ему другим праводателем, они выводятся в отдельном элементе aclitem . Пустое поле правообладателя в aclitem соответствует роли PUBLIC .

Например, предположим, что пользователь miriam создаёт таблицы mytable и выполняет:

GRANT SELECT ON mytable TO PUBLIC; GRANT SELECT, UPDATE, INSERT ON mytable TO admin; GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;

Тогда команда \dp в psql покажет:

=> \dp mytable Access privileges Schema | Name | Type | Access privileges | Column privileges | Policies --------+---------+-------+-----------------------+-----------------------+---------- public | mytable | table | miriam=arwdDxt/miriam+| col1: +| | | | =r/miriam +| miriam_rw=rw/miriam | | | | admin=arw/miriam | | (1 row)

Если столбец « Права доступа » (Access privileges) для данного объекта пуст, это значит, что для объекта действуют стандартные права (то есть запись прав в соответствующем каталоге содержит NULL). Права по умолчанию всегда включают все права для владельца и могут также включать некоторые права для PUBLIC в зависимости от типа объекта, как разъяснялось выше. Первая команда GRANT или REVOKE для объекта приводит к созданию записи прав по умолчанию (например, ), а затем изменяет эту запись в соответствии с заданным запросом. Подобным образом, строки, показанные в столбце « Права доступа к столбцам » (Column privileges), выводятся только для столбцов с нестандартными правами доступа. (Заметьте, что в данном контексте под « стандартными правами » всегда подразумевается встроенный набор прав, предопределённый для типа объекта. Если с объектом связан набор прав по умолчанию, полученный после изменения в результате ALTER DEFAULT PRIVILEGES , изменённые права будут всегда выводиться явно, показывая эффект команды ALTER .)

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

Пред. Наверх След.
5.6. Изменение таблиц Начало 5.8. Политики защиты строк

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

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