Созданный пользователь может получить доступ ко всем базам данных в PostgreSQL без каких-либо прав

44

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

Вот что я делаю на Ubuntu Server 12.04:

apt-get установить postgresql
sudo -u postgres createuser -DRSP mike1 (указание пароля для нового пользователя)
sudo -u postgres созданный data1
psql -h localhost -U mike1 data1 (указание пароля для входа в систему пользователя mike1)

Кажется, что у нового пользователя "mike1" нет проблем с подключением к базе данных "data1", созданием таблиц и т. Д. И это вообще без какой-либо команды GRANT (а владельцем "data1" является "postgres", так как я не указал владелец на шаге 3). Это действительно, как это должно работать?

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

postgresql permissions

— mikeplate
источник

1

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

— кгритт

47

На уровне SQL каждый пользователь может подключаться к вновь созданной базе данных, пока не будет выполнена следующая команда SQL:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

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

GRANT connect ON DATABASE database_name TO rolename;

Изменить: В сценарии с несколькими арендаторами, connectбудет удалено больше, чем просто привилегия. Чтобы получить советы и рекомендации по работе с несколькими арендаторами, вы можете прочитать на общедоступной вики-странице postgresql: Хостинг общих баз данных и управление правами в PostgreSQL .

— Даниэль Верите
источник

По умолчанию должно было быть наоборот. Я хочу создать пользователя со случайно сгенерированным паролем и предоставить ему доступ к одной БД, зная, что postgresможет получить доступ ко всем базам данных.

— TheRealChx101

24

PUBLIC имеет доступ к базе данных по умолчанию, но не может получить доступ к данным. Вы можете отменить публикацию:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Если вы хотите этот параметр для всех будущих баз данных, отмените CONNECT в базе данных template1 (база данных шаблона по умолчанию для создания новой базы данных):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;

— Фрэнк Хейкенс
источник

Понимаю. Теперь это имеет больше смысла. Думаю, мне не следует приходить сюда новичком в PostgreSQL и спорить, что, возможно, PUBLIC не должен иметь привилегию CONNECT для template1 по умолчанию :) Но теперь я также вижу, что данные никогда не подвергались опасности. Благодарность!

— mikeplate

1

Мы рады приветствовать вас как новичка, а также оспаривать настройки. Каждый может учиться на этом!

— Фрэнк Хайкенс,

1

На самом деле, эта привилегия CONNECT не передается из шаблона в новую базу данных, поэтому отзыв ее в template1 не имеет упомянутого эффекта.

— Даниэль Верите

2

@ DanielVérité, я вижу. Поэтому я думаю, что решение состоит в том, чтобы всегда помнить и выполнять REVOKE CONNECT при создании новой базы данных. Это действительно так, как это обычно делают администраторы PostgreSQL, или меня не должно волновать, что данные все равно недоступны? Тем не менее, я думаю, что список таблиц может выдавать ненужную информацию для будущих атак, если только между уже авторизованными пользователями в многопользовательской среде. Также: только что понял, что public также может создавать свои собственные таблицы в любой базе данных, которая не была REVOKE CONNECT. Должен сказать, немного странно иметь по умолчанию.

— mikeplate

1

Да. Я добавляю ссылки на свой ответ, вы можете прочитать еще пару документов по этому вопросу.

— Даниэль Верите

4

Помимо отзыва привилегий подключения из PUBLIC по умолчанию и предоставления их по желанию, другой уровень, на котором вы можете контролировать доступ, - через файл pg_hba.conf.

Вы можете найти, где хранится файл:

SHOW hba_file;

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

http://www.postgresql.org/docs/current/interactive/auth-pg-hba-conf.html

— kgrittn
источник

Благодарность! Я просмотрел файл pg_hba.conf, но у меня сложилось впечатление, что он определяет только то, как пользователь аутентифицируется при подключении к базе данных, а не то, какие привилегии пользователь имеет в той же базе данных.

— mikeplate

1

Пользователь может подключаться к базам данных только так, как разрешено в pg_hba.conf. Это включает в себя не только комбинацию пользователя и базы данных, но также хост, с которого они соединяются, и разрешенный метод аутентификации. Если вам не нужно , что детальность контроля, GRANT/ REVOKEтехник обсуждается в других ответах, наверное , проще. Во-первых, для этого вам просто нужно соединение с базой данных суперпользователя, а не логин ОС, который может редактировать файл.

— kgrittn

0

Я наткнулся на эту тему в поисках способа запретить пользователям даже перечислять другие имена баз данных. Это REVOKE CONNECTне мешает этому.

В соответствии с ответами на этот вопрос SO нет (рекомендуемый) способ достичь этого.

— AdamAL
источник