The first comment nailed the most likely reason this is happening. Quoting the release announcement:
PostgreSQL 15 also revokes the
CREATEpermission from all users except a database owner from thepublic(or default) schema.
The reason your fix didn’t work is that all actions you took on database postgres in regards to user admin‘s privileges on schema public concern only that schema within the database postgres. Schema public on database postgres is not the same schema public as the one on newly created mydb.
Also, this:
GRANT ALL ON DATABASE mydb TO admin;
grants privileges on the database itself, not things within the database. admin can now drop the database, for example, still without being able to create tables in schema public. My guess is that you wanted to make admin also the owner of mydb, in which case you need to add
ALTER DATABASE mydb OWNER TO admin;
Or you need to repeat your GRANT USAGE, CREATE ON SCHEMA public TO admin; on mydb.
Here’s some more documentation on secure schema usage patterns the PostgreSQL 15 change was based on.
I kept getting this error when using flyway to deploy database changes. I do some manual setup first, such as creating the database, so flyway wouldn’t need those super-admin permissions.
My Fix
I had to ensure that the database user that flyway job used had ownership rights to the public schema, so that the flyway user could then assign the right to use the schema to other roles.
Additional setup Details
I am using AWS RDS (both regular and Aurora), and they don’t allow super users in the databases. RDS reserves super users for use by AWS, only, so that consumers are unable to break the replication stuff that is built in. However, there’s a catch-22 that you must be an owner in postgres to be able to modify it.
My solution was to create a role that acts as the owner (‘owner role’), and then assign both my admin user and the flyway user to the owner role, and use ALTER scripts for each object to assign the object’s owner to the owner role.
I missed the public schema, since that was auto-created when I created the database script manually. The public schema defaulted to my admin role rather than the shared owner role. So when the flyway user tried to assign public schema permissions to other roles, it didn’t have the authority to do that. An error was not thrown during flyway execution, however.
I kept getting this error when using flyway to deploy database changes. I do some manual setup first, such as creating the database, so flyway wouldn’t need those super-admin permissions.
My Fix
I had to ensure that the database user that flyway job used had ownership rights to the public schema, so that the flyway user could then assign the right to use the schema to other roles.
Additional setup Details
I am using AWS RDS (both regular and Aurora), and they don’t allow super users in the databases. RDS reserves super users for use by AWS, only, so that consumers are unable to break the replication stuff that is built in. However, there’s a catch-22 that you must be an owner in postgres to be able to modify it.
My solution was to create a role that acts as the owner (‘owner role’), and then assign both my admin user and the flyway user to the owner role, and use ALTER scripts for each object to assign the object’s owner to the owner role.
I missed the public schema, since that was auto-created when I created the database script manually. The public schema defaulted to my admin role rather than the shared owner role. So when the flyway user tried to assign public schema permissions to other roles, it didn’t have the authority to do that. An error was not thrown during flyway execution, however.
In Postgres I created the following table inside a db called testing:
CREATE TABLE category_google_taxonomy (
category_id integer references category ON UPDATE CASCADE ON DELETE CASCADE,
google_taxonomy_id integer references google_taxonomy ON UPDATE CASCADE ON DELETE CASCADE
);
When I try to populate the table:
INSERT INTO category_google_taxonomy (category_id, google_taxonomy_id) VALUES
(1,7),
(2,12);
I get the following error:
ERROR: permission denied for schema public
LINE 1: SELECT 1 FROM ONLY "public"."category" x WHERE "category_id"...
^
QUERY: SELECT 1 FROM ONLY "public"."category" x WHERE "category_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x
I read up a bit and eventually granted ALL PRIVILEGES out of exasperation, but it still doesn’t work:
testing=# GRANT ALL PRIVILEGES ON public.category TO testing;
GRANT
testing=# dp category_google_taxonomy
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+--------------------------+-------+-------------------------+--------------------------
public | category_google_taxonomy | table | testing=arwdDxt/testing |
: super=arwdDxt/testing
testing=# dp category
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+----------+-------+------------------------+--------------------------
public | category | table | testing=arwdDxt/super | category_id:
: testing=arwx/super
(1 row)
On @Daniel’s suggestion I tried GRANT USAGE ON schema public TO super;, now when I run the INSERT command I get:
ERROR: permission denied for relation category
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."category" x WHERE "category_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
Here is the relevant part of d:
public | category | table | super
public | category_google_taxonomy | table | testing
Я запускаю Postgres 10.4 и в настоящее время сбит с толку, поскольку не могу предоставить доступ к схеме другой роли.
Что я хочу сделать:
У меня одна роль с одной схемой, и я хочу получить доступ к схеме и ее таблицам из другой роли. Итак, я сделал как обычно (что работало с другими схемами):
grant usage on schema myschema to newuser;
grant select on all tables in schema myschema to newuser;
Оба этих оператора выполнялись как владелец схемы. При этом я не столкнулся с какими-либо ошибками.
Когда я вхожу в систему как новый пользователь и пытаюсь выбрать некоторые данные:
select * from myschema.table;
Я получаю сообщение об ошибке:
SQL Error [42501]: ERROR: permission denied for schema myschema
Я вижу, что у нового пользователя есть нужные привилегии в таблице «information_schema.role_table_grants»
Он также работал с другой ролью и другой схемой. Я невежественен.
Ответы
2
Это определенно работает, как указано в моем вопросе, проблема заключалась в том, что я не использовал владельца схемы.
Поэтому всегда убедитесь, что вы предоставляете доступ к схеме от роли владельца.
Шаг 1
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA name_schema TO name_user;
Шаг 2
GRANT USAGE ON SCHEMA name_schema TO name_user;
Другие вопросы по теме
|
NataNov 0 / 0 / 0 Регистрация: 09.04.2021 Сообщений: 4 |
||||||||||||
|
1 |
||||||||||||
Создание пользователя с правами на таблицы в схеме09.04.2021, 14:54. Показов 4679. Ответов 1 Метки нет (Все метки)
Добрый день!
Затем подключаюсь к базе my_db под пользователем user1: c my_db user1 До сих пор все шло прекрасно. Но дальше пытаюсь сделать select от имени пользователя user1:
выходит ошибка — нет доступа к схеме my_schema пытаюсь по другому:
Ошибка — нет доступа к таблице my_table! Что я делаю не так?!
__________________
0 |
|
grgdvo 1184 / 914 / 367 Регистрация: 02.09.2012 Сообщений: 2,785 |
||||
|
10.04.2021, 09:09 |
2 |
|||
|
Решение Схема — такой же объект базы, как и таблицы.
1 |
Допустим, я сделал эту «простую» реализацию БД в Postgres.
postgres=# CREATE ROLE my_role;
CREATE DATABASE my_db;
GRANT ALL ON DATABASE my_db TO my_role;
CREATE SCHEMA my_schm AUTHORIZATION my_role;
А потом я хочу сделать таблицу:
postgres=#CREATE TABLE IF NOT EXIST my_db.my_schm.table(...);
И получил следующую ошибку: cross-database references are not implemented: "my_db.my_schm.table"
После этого я попытался создать таблицу, подключенную к базе данных (т.е. c my_db), и получил следующую ошибку:
schema "my_schm"does not exist
Итак, я не понимаю поведения этих ошибок. Предполагается, что роль имеет все разрешения для базы данных (и да, я также пробовал использовать SET ROLE my_role;), но когда я прошу показать схемы в my_db действительно my_schm не существует, но в Postgres он есть. Может кто-нибудь объяснить мне, пожалуйста, почему это происходит? А также как сгруппировать таблицы в my_schm?
1 ответ
Лучший ответ
Схемы существуют только в одной базе данных и создаются в текущей базе данных: вы создали свою схему в базе данных postgres, а не в mydb.
Вам необходимо сначала подключиться к базе данных mydb, чтобы создать схему в базе данных mydb.
3
pifor
24 Май 2020 в 10:56
|
|
|
|

информация о разделе
![]() |
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных — обсуждаем в разделе «Базы данных: общие вопросы». Убедительная просьба — соблюдать «Правила форума» и не пренебрегать «Правильным оформлением своих тем». Прежде, чем создавать тему, имеет смысл заглянуть в раздел «Базы данных: FAQ», возможно там уже есть ответ. |

разные пользователи и доступ
, не могу разобраться с ролями
- Подписаться на тему
- Сообщить другу
- Скачать/распечатать тему
|
|
|
|
Senior Member
Рейтинг (т): 13 |
Здравствуйте, Господа!
#psql postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# GRANT ALL PRIVILEGES ON DATABASE db1 TO user1; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# GRANT ALL PRIVILEGES ON DATABASE db1 TO user2; postgres=# q #psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES («u1», «p1»); db1=# q #psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES («u2», «p2»); ОШИБКА: нет доступа к отношению users Вот тут я в растерянности. Оба пользователя ALL PRIVILEGES для db1, но второй, т.е. не создатель таблицы, добавлять записи не может. |
|
grgdvo |
|
|
Member
Рейтинг (т): 21 |
Опция ALL PRIVILEGES для DATABASE подразумевает CREATE, CONNECT и кажется TEMP привилегии для базы данных. |
|
HighMan |
|
|
Senior Member
Рейтинг (т): 13 |
Цитата grgdvo @ 14.10.15, 12:36 Опция ALL PRIVILEGES для DATABASE подразумевает CREATE, CONNECT и кажется TEMP привилегии для базы данных. Простите бестолкового, а как для схем предоставить привилегии? Сообщение отредактировано: HighMan — 14.10.15, 14:58 |
|
grgdvo |
|
|
Member
Рейтинг (т): 21 |
Цитата HighMan @ 14.10.15, 14:57 Простите бестолкового, а как для схем предоставить привилегии?
В конце я неправ, забываешь как оно работает, когда не пользуешься. Нужны команды конкретно на таблицу или ALL TABLES IN SCHEMA. Для вашего примера скорее всего правильный порядок будет такой
~ # psql -U postgres postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# q db1 создается со схемой public по умолчанию, в которой пользователи уже могут создавать таблицы (и т.д.), поэтому user1 и user2 смогут создать свои объекты базы
~ # psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES (‘u1’, ‘p1’); db1=# q теперь к user_ids и users доступ имеет только user1, ибо он владелец этих объектов.
~ # psql -U postgres db1 db1=# GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO user2; db1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user2; Теперь user2 имеет все привилегии на таблицы и последовательнсти, которые УЖЕ БЫЛИ СОЗДАНЫ на данный момент в схеме.
~ # psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES (‘u2’, ‘p2’); Сообщение отредактировано: grgdvo — 14.10.15, 20:28 |
|
HighMan |
|
|
Senior Member
Рейтинг (т): 13 |
Цитата grgdvo @ 14.10.15, 20:28 Цитата HighMan @ 14.10.15, 14:57 Простите бестолкового, а как для схем предоставить привилегии?
В конце я неправ, забываешь как оно работает, когда не пользуешься. Нужны команды конкретно на таблицу или ALL TABLES IN SCHEMA. Для вашего примера скорее всего правильный порядок будет такой
~ # psql -U postgres postgres=# CREATE USER user1 WITH password ‘password’; postgres=# CREATE USER user2 WITH password ‘password’; postgres=# CREATE DATABASE db1; postgres=# q db1 создается со схемой public по умолчанию, в которой пользователи уже могут создавать таблицы (и т.д.), поэтому user1 и user2 смогут создать свои объекты базы
~ # psql -U user1 db1 db1=# CREATE SEQUENCE user_ids; db1=# CREATE TABLE users (id INTEGER PRIMARY KEY DEFAULT NEXTVAL(‘user_ids’), login CHAR(64), password CHAR(64)); db1=# INSERT INTO users (login, password) VALUES (‘u1’, ‘p1’); db1=# q теперь к user_ids и users доступ имеет только user1, ибо он владелец этих объектов.
~ # psql -U postgres db1 db1=# GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO user2; db1=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user2; Теперь user2 имеет все привилегии на таблицы и последовательнсти, которые УЖЕ БЫЛИ СОЗДАНЫ на данный момент в схеме.
~ # psql -U user2 db1 db1=# INSERT INTO users (login, password) VALUES (‘u2’, ‘p2’);
Спасибо большое! |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
- Предыдущая тема
- Базы данных: SQL
- Следующая тема
[ Script execution time: 0,0347 ] [ 15 queries used ] [ Generated: 30.01.23, 08:58 GMT ]
Сообщение было отмечено NataNov как решение




