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


44

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

Ось що я роблю на сервері Ubuntu 12.04:

  1. apt-get install postgresql
  2. sudo -u postgres createuser -DRSP mike1 (Вказання пароля для нового користувача)
  3. sudo -u postgres створенийb data1
  4. psql -h localhost -U mike1 data1 (Зазначення пароля користувача mike1 для входу)

Здається, що у нового користувача "mike1" немає проблем з підключенням до бази даних "data1" та створенням таблиць тощо. І це без запуску жодної команди GRANT (а власник "data1" - "postgres", оскільки я не вказав власник на кроці 3). Чи справді це має працювати?

Що я хотів би зробити, це надати mike1 повний доступ до data1, а потім повторити це для більшої кількості користувачів та баз даних, переконуючись, що користувачі мають доступ лише до однієї (або, можливо, декількох) моїх баз даних.


1
Майте на увазі, що навіть якщо користувач обмежений однією базою даних, вони все ще можуть запитувати глобальні таблиці, що дозволить їм бачити список імен бази даних та список користувачів.
kgrittn

Відповіді:


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 за замовчуванням :) Але я також бачу, що дані ніколи не піддавалися небезпеці. Дякую!
міксель

1
Ви, як новачок, також більш ніж бажані, щоб оскаржити налаштування. На цьому може навчитися кожен!
Френк Хайкенс

1
Власне, ця привілей CONNECT не передається з шаблону в нову базу даних, тому відкликання його на template1 не має згаданого ефекту.
Даніель Верете

2
@ DanielVérité Я бачу. Тому я гадаю, що рішення завжди пам’ятати та робити РЕКЛАМНУВАННЯ під час створення нової бази даних. Це дійсно так, як це зазвичай роблять адміністратори PostgreSQL, чи мені це не важливо, оскільки дані так чи інакше недоступні? І все-таки я думаю, що список таблиць може видавати непотрібну інформацію для майбутніх атак, якщо тільки між вже авторизованими користувачами в середовищі, що має багато орендарів. Також: щойно зрозумів, що публіка також може створювати власні таблиці в будь-якій базі даних, яка не була ЗАМИНАЄТЬСЯ ЗВ'ЯЗАТИ Я повинен сказати, що це дещо дивно.
міксель

1
Так. Я додаю відповідні посилання до своєї відповіді, ви можете прочитати ще кілька документів про це.
Даніель Верете

4

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

Ви можете знайти, де зберігається файл:

SHOW hba_file;

Якщо ви вирішили використовувати цей механізм, є вбудовані коментарі, яких може бути достатньо для початку роботи. Документи тут:

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


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

1
Користувач може підключатися до баз даних, як це дозволено pg_hba.conf. Це включає не тільки комбінацію користувача та бази даних, але й хост, з яким вони з'єднуються, та дозволений метод аутентифікації. Якщо вам не потрібна деталізація контролю, GRANT/ REVOKEтехніку, обговорювану в інших відповідях, напевно, простіше. З одного боку, для цього вам просто потрібне підключення до бази даних суперпользователя, порівняно з необхідністю входу в ОС, який може редагувати файл.
kgrittn

0

Я натрапив на цю тему, шукаючи способу не допустити користувачів навіть перелічувати інші імена бази даних. Це REVOKE CONNECTне заважає.

Відповідно до відповідей на це питання ТА немає (рекомендованого) способу його досягнення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.