PostgreSQL права користувача
Для початку роботи вам знадобиться власне PostgreSQL сервер і доступ до його консолі. Якщо ви хочете просто попрацювати в режимі лабораторії, можна скористатися free tier (безкоштовною пробною версією) в одному з клаудів, наприклад AWS, або швидко підняти PostgreSQL на лептопі, використовуючи docker:
docker run -d --name postgres postgres
docker exec -ti postgres psql -U postgres
Користувач "postgres" - користувач PostgreSQL за замовчуванням. Він також є суперкористувачем. При підключенні через сокет зазвичай пароль не потрібний. Підключення TCP/IP однак може супроводжуватися запитом пароля, але в більшості установок PostgreSQL пароль postgres за замовчуванням "postgres".
На замітку: у PostgreSQL права суперкористувача не обмежені, проте щоб змінити суперкористувача або створити нового, вам самим потрібно бути суперкористувачем.
Ви завжди починаєте з того, що заходите суперкористувачем, а далі вже створюєте непривілейованих користувачів, бази, схеми тощо. Хоча правильніше буде говорити "ролі", оскільки з версії 8.1 користувачі та групи PostgreSQL були замінені на ролі. Ролі можуть бути членами інших ролей - у цьому випадку вони виступають аналогом групи, але в найпростішому випадку роль PostgreSQL слід інтерпретувати як звичайного користувача
Щоб у PostgreSQL створити роль введіть у консоль
CREATE ROLE test WITH LOGIN PASSWORD 'test';
Ця команда дозволяє в PostgreSQL створити роль з ім'ям "test" та паролем "test" і, увага - ми вже почали працювати з правами, видати їй право підключатися з серверу баз даних. Дуже важливо – загостріть увагу на слові "сервер баз даних", тому що цей привілей регулює саме можливість підключення до сервера, але не до бази. Так, на відміну від того ж MySQL, PostgreSQL поділяє ці два поняття. Тобто.якщо у вас є право підключатися до сервера баз даних (PostgreSQL), це ще далеко не факт, що у вас є право підключатися до баз, що зберігаються на цьому сервері. Якщо LOGIN не вказати, то за промовчанням нові ролі такого привілею не отримують і не можуть підключатися до сервера баз даних. А навіщо нам взагалі може знадобитися без права підключення до сервера баз даних? Наприклад, знімаючи цей атрибут, ми можемо тимчасово блокувати користувачів, або використовувати такі ролі як групи, тобто. Видаючи права на групу, ми зазвичай не хочемо, щоб хтось міг підключатися від імені самої групи.
Давайте подивимося, які атрибути ми можемо передавати команді CREATE ROLE
І так у нас є роль "test", а це означає, що час створити базу та дати нашій ролі право читання чи запису до цієї бази. Як було зазначено вище, ми можемо дати право самій ролі створювати бази, або створити її від імені суперкористувача. Вибір за вами, якщо ви вказали під час створення ролі атрибут CREATEDB, то можете сміливо перепідключатись, використовуючи роль "test". Якщо ні, то тут два шляхи: продовжити від імені суперкористувача або дати роль право створення баз. Зробити це можна командою ALTER ROLE як показано нижче
ALTER ROLE test CREATEDB;
Перевіримо наш сетап. У PostgreSQL список ролей можна отримати командою '\du'
postgres=# \du
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
test | Create DB | <>
.
Тепер можна перейти до створення бази. Зробити можна таким чином
CREATE DATABASE test WITH ENCODING UTF8;
База створена! Як і у разі створення ролей, при створенні бази теж можна вказати ряд атрибутів. Давайте розглянемо найцікавіші з погляду прав доступу
Почнемо із OWNER. Ми цим плавно підійшли до концепції володіння. У PostgreSQL діє правило: той, хто об'єкт створює, чи то база, схема, таблиця чи щось інше, отримує необмежені права на цей об'єкт.Тобто, якщо ви створювали бази від імені суперкористувача, то він матиме цю базу і всі права на неї, якщо від імені ролі, то роль. І жодні інші непривілейовані ролі до цих об'єктів доступ мати не будуть.
Здавалося б логічно, але ні. У PostgreSQL є така штука як PUBLIC - неявна псевдо роль, неявними членами якої є ролі. І в неї є деякі права за замовчуванням, які деяких змушують свербіти. Наприклад, ви створили базу, і навіть не важливо від імені суперкористувача або непривілейованої ролі, тут хтось інший логіниться і починає абсолютно спокійно створювати у вашій базі таблиці, і PostreSLQ навіть не заикнеться, що можливо це не те, що ви мали на увазі . Чому так і як це лікувати? Давайте розбиратися
Почати мабуть варто з концепції наймспейсингу
Цей малюнок говорить про те, що ваші таблиці, в'юзи та інші елементи бази даних повинні мати унікальні імена лише в межах схеми. Схема в PostgreSQL це такий аналог неймаспейсів. Тобто. як сервер баз даних може зберігати деяку кількість власне баз даних, так і кожна база даних всередині цього сервера може містити деяку кількість схем.
На замітку: PostgreSQL не надає можливість працювати зі схемою однієї бази, будучи підключеним до іншої. Щоб попрацювати зі схемою іншої бази необхідно перепідключитися, вказавши потрібне ім'я бази
Кожна база повинна мати хоча б одну схему, і вона створюється за умовчанням при створенні бази і зветься PUBLIC. Звідси й ноги ростуть у проблем із надмірно дозвільними правами доступу. Але вже одного разу створивши таблицю навіть у схемі PUBLIC, скажімо від імені непривілейованої ролі, вже ніякі інші ролі доступу до даних, що зберігаються всередині цієї таблиці, не отримають. Однак, вони все ще зможуть вивести список ваших таблиць.
Як вирішити цю проблему, якщо вас не влаштовує такий стан справ? Що ж, вирішувати треба насправді дві проблеми. По-перше, відібрати у PUBLIC можливість підключатися до бази даних:
REVOKE ALL PRIVILEGES ON DATABASE test FROM PUBLIC;
GRANT CONNECT ON DATABASE до test;
Даний сет команд знімає всі привілеї з PUBLIC щодо бази даних "test", а їх ми нагадаємо всього 4: CREATE, CONNECT, TEMPORARY та TEMP, і видає ролі "test" можливість лише підключатися до бази даних
Варіантів вирішення проблеми зі схемою рівно два: створити схему відмінну від PUBLIC. Там уже ніякі налаштування за замовчуванням до вас не дістануться. Ви створили схему – ви її власник. Всім іншим для доступу до схеми знадобиться явний дозвіл вас чи суперкористувача. Або навпаки, як і у випадку з базою, відібрати у PUBLIC доступ власне до PUBLIC схеми. Зробити це можна командою
REVOKE ALL PRIVILEGES ON SCHEMA public FROM PUBLIC;
Після такого ніхто не те що створювати таблиці – переглянути список таблиць вже не зможе. Якщо ви все ж таки хочете залишити можливість перегляду списку таблиць, то такий привілей треба тепер явно видати якийсь конкретної ролі або всім (PUBLIC)
GRANT USAGE ON SCHEMA public TO PUBLIC
Давайте підсумуємо знання про права за замовчуванням PUBLIC (зауважте, ми спеціально не називаємо це роллю) у таблиці
Право читати та писати в елементи бази даних за замовчуванням є лише у власника. Потрібен явний дозвіл іншим ролям для зняття цього обмеження
Ідемо далі. А далі – гірше. Ми розібралися із сервером баз даних, базами та схемами. А як елементи бази даних, такі як таблиці, в'юзи, послідовності? Тут теж є, що налаштовувати, особливо якщо вам потрібно в PostgreSQL створити користувача і дати права тільки на читання (readonly) для, наприклад, виконання дампа або гранту команді аналізу лімітованого доступу до даних. Відповідно послідовність операцій буде такою:
- Створюємо нову роль
- Видаємо ролі можливість підключатися до бази
- Даємо можливість ролі читати схему public, або іншу, якщо ви не хочете працювати зі схемою public
- Даємо можливість читати таблиці у зазначеній схемі
Припустимо, ви працюєте в схемі public, то в командах PostgreSQL це буде виглядати так
CREATE ROLE ro_user WITH LOGIN NOINHERIT PASSWORD 'changeme';
GRANT CONNECT ON DATABASE test TO ro_user;
GRANT USAGE ON SCHEMA public TO ro_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO ro_user;
І ось, начебто момент щастя, але PostgreSQL і тут свиню підклав. Якщо після такої операції ви створили нову таблицю, то увага, ваша ro_user не матиме до неї доступу! Вирішити проблему можна, виконавши команди вище ще раз, або ж попрацювати над такою штукою, як привілеї за замовчуванням. Відповідно, щоб ro_user міг радісно читати дані навіть із новостворених таблиць, вам слід виконати
ALTER DEFAULT PRIVILEGES IN SCHEMA Public GRANT SELECT ON TABLES TO ro_user;
Якщо структура бази трохи складніша, ніж зазвичай, можливо вам знадобиться дати права також на послідовності та процедури
ALTER DEFAULT PRIVILEGES IN SCHEMA Public GRANT USAGE,SELECT ON SEQUENCES TO ro_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA Public GRANT EXECUTE ON ROUTINES TO ro_user;
Управління користувачами в PostgreSQL
PostgreSQL – система управління базами даних (СУБД) із відкритим вихідним кодом. Її робота ґрунтується на стандартній мові запитів SQL. Системні адміністратори вибирають цей інструмент із кількох причин: безкоштовне використання, висока продуктивність практично на будь-якій апаратній платформі. У нашому випадку достатньо орендувати один із тарифів хмарних баз даних у провайдера Timeweb Cloud.
У цьому матеріалі ми розберемо, як створити та видалити користувача в PostgreSQL, налаштувати права доступу, як використовувати обліковий запис на практиці (на прикладі створення резервних копій).Зазначимо, що наведені у статті процедури виконуються в оболонці PostgreSQL. Її можна запустити від імені облікового запису postgres:
При видачі помилки про недостатні права – підвищуйте їх командою sudo su або su. Тепер можна стартувати саму командну оболонку:
$ psql -U postgres template1де template1 - це шаблонний приклад БД, у своєму випадку вкажіть будь-яку іншу. Робота йтиме під обліком postgres. Перед подальшими діями переглянемо список існуючих користувачів СУБД:
select * from pg_user;Створимо новий обліковий запис
Перше, що нам потрібно зробити – створити користувача з паролем. Також треба призначити йому певні привілеї через налаштування файлу pg_hba.conf.
Крок 1. Створимо користувача
Задамо роль користувача приклад команди з оболонки SQL:
CREATE USER user123 WITH PASSWORD 'myPassword';Те саме, але за допомогою командного рядка Linux:
createuser -P user123Крок 2. Призначимо права для операцій із БД
Права поставимо командою:
GRANT ALL PRIVILEGES ON DATABASE "database1" to user123;Тепер можна активувати підключення до бази:
Задамо права працювати з таблицями в аналізованої нами БД database1 і обліку user123:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "user123";Зазначимо, що за умовчанням система налаштована на схему public, але користувачеві доступна її зміна та вибір нової.
При призначенні прав можна вказати певну таблицю:
GRANT ALL PRIVILEGES ON TABLE table1 IN SCHEMA public TO "user123";Користувач PostgreSQL створений, можна закривати оболонку та працювати далі:
Крок 3. Налаштуємо файл pg_hba.conf
Перевіримо, які привілеї задано без зміни налаштувань. Вони записані у файлі pg_hba.conf. Відкриємо його на редагування:
vi /var/lib/pgsql/12/data/pg_hba.confНаступний крок керування користувачем PostgreSQL – додавання прав нового облікового запису:
# IPv4 local connections:
host all user123 127.0.0.1/32 md5Команда дозволяє користувачеві з ім'ям user123 підключатися до будь-яких баз, розміщених на сервері. Важливо внести зазначену інформацію вище за рядок, що є за замовчуванням:
host all all 127.0.0.1/32 identЩоб налаштування застосували, перезапустимо службу:
systemctl restart postgresqlУ цьому прикладі йдеться про СУБД PostgreSQL12.
Крок 4. Протестуємо працездатність БД
Перевіримо підключення щойно створеного користувача:
psql -U user123 template1 -h 127.0.0.1Налаштуємо права доступу до БД через групу
Перша дія – створимо групову роль:
CREATE ROLE "myRole" NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;Наступним кроком внесемо до неї нашого користувача user123:
GRANT "myRole" TO user123;Тепер можна підключатися до БД:
І налаштувати привілеї для гурту myRole:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO GROUP "myRole";Відредагуємо користувача
Переналаштувати систему так само просто, як створити користувача адміністратора. Наприклад змінимо пароль раніше створеного нами облікового запису. Виконується це однією командою:
ALTER USER postgres PASSWORD 'password'Та ж операція доступна і в командному рядку Linux:
sudo -u postgres psql -U postgres -d postgres -c "ALTER USER postgres PASSWORD 'password'"Видалимо обліковий запис і групу
Команда видалення користувача виглядає так:
Замість видалення можна обмежити обліковий запис у правах:
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM "user123";Призначимо особливі привілеї існуючого облікового запису
При керуванні користувачами та повноваженнями у СУБД PostgreSQL можна задавати як «повні» права ALL PRIVILEGES, так і особливі:
GRANT SELECT, UPDATE, INSERT ON ALL TABLES IN SCHEMA public TO "user123";Наведений приклад дозволяє користувачеві user123 зчитувати, редагувати та додавати нові дані. Але видаляти нічого не можна, такі операції команда забороняє. Якщо потрібно призначити права для роботи з конкретною таблицею, команда набуде такого вигляду:
GRANT ALL PRIVILEGES ON table_users TO "user123";Створимо облік для резервування БД
Створювати резервні копії рекомендуємо з мінімальними правами. Створимо роль користувача на читання PostgreSQL для виконання процедури:
CREATE USER bkpuser WITH PASSWORD 'bkppasswd';Тут ми створили облік bkpuser і задали їй пароль bkppasswd, їх можна замінити на свої. Потім активуємо можливість підключатися до бази:
GRANT CONNECT ON DATABASE database TO bkpuser;Можна підключитися до БД:
І надавати необхідні права:
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO bkpuser;У цьому прикладі використана схема public, її можна замінити іншою.
Докладніше про резервне копіювання PostgreSQL ми писали у статті Дампи у PostgreSQL: резервне копіювання та відновлення.
Висновки
Ми завершили розгляд методики, як створювати користувачів PostgreSQL через консоль та налаштовувати їхні права. Іноді зручніше працювати через програми з графічним інтерфейсом на зразок pgAdmin, це вибір користувача. Поекспериментувати без ризику пошкодити робочі БД простіше на орендованих потужностях провайдера Timeweb Cloud.
До речі, в офіційному каналі Timeweb Cloud зібрали ком'юніті із фахівців, які говорять про IT-тренди, діляться корисними інструкціями та навіть запрошують до себе працювати.
Як використовувати ролі та керувати наданням прав у PostgreSQL на VPS
PostgreSQL, або Postgres є системою управління реляційними базами даних з відкритим вихідним кодом. Як і інші реляційні бази даних, PostgreSQL зберігає дані у таблицях, які з рядків і стовпців. Користувачі можуть визначати, керувати, контролювати та запитувати дані, використовуючи мову структурованих запитів, більш відомий як SQL. PostgreSQL – потужний інструмент, який можна використовувати для керування програмами та веб-даними на віртуальному приватному сервері.
Цей посібник покаже, як правильно керувати привілеями та надавати дозволи користувачам.Це дозволить вам надати додаткам необхідні привілеї без впливу на окремі бази даних.
Попередні умови
Для виконання цього посібника вам знадобиться:
- Один сервер Ubuntu 22.04, налаштований відповідно до нашого Посібника з початкового настроювання сервера для Ubuntu 22.04. Після завершення цього обов'язкового керівництва на вашому сервері має бути створений не-root користувач із правами sudo та базовий брандмауер.
- Для завершення Крок 1 нашого уроку Як встановити та використовувати PostgreSQL на Ubuntu 22.04 для встановлення Postgres на вашому сервері.
З вашим середовищем підготовленої та Postgres запущеним на вашому сервері, ви можете почати вивчати те, як Postgres обробляє дозволи.
Перегляд ролей та дозволів у PostgreSQL
Postgres керує дозволами через концепцію ролей. Ролі відрізняються від традиційних дозволів у стилі Unix тим, що немає різниці між користувачами та групами. Ролі можна налаштувати так, щоб вони нагадували обидві ці конвенції, але вони також гнучкіші. Під час встановлення Postgres налаштований на використання автентифікації peerщо означає, що він пов'язує ролі Postgres з відповідним обліковим записом системи Unix/Linux. Якщо роль існує в Postgres, користувач з іменем Unix/Linux також може увійти під цю роль.
Під час встановлення створено обліковий запис користувача з ім'ям postgres, пов'язана з роллю Postgres за промовчанням. Для використання Postgres ви можете увійти до цього облікового запису.
Спочатку переконайтеся, що ваш сервер працює, використовуючи команду systemctl start :
Потім ви можете перейти на обліковий запис postgres, набравши:
Тепер ви можете одразу отримати доступ до запрошення PostgreSQL, набравши:
Щоб перерахувати ролі у вашому екземплярі Postgres, виконайте наступну команду:
Output List roles Role name | Attributes | Member of -----------+------------------------------------ ------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <>
В даний час є лише одна роль за умовчанням з безліччю потужних привілеїв.
Створення ролей у PostgreSQL
Існує кілька способів створення ролей для Postgres. Можна створювати ролі зсередини Postgres або командного рядка.
Створення ролей зсередини PostgreSQL
Один із способів створення нової ролі – з інтерфейсу командного рядка Postgres. Нижче наведено синтаксис для створення нової ролі в інтерфейсі командного рядка Postgres:
Щоб продемонструвати це, створіть нову роль з ім'ям demo_role:
Перевірте певних користувачів знову:
Output List roles Role name | Attributes | Member of -----------+------------------------------------ ------------------------+----------- demo_role | Cannot login | <> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <>
Ваш висновок покаже двох користувачів.
Створення ролей з командного рядка
Альтернативним методом створення ролей є використання команди створеногокористувача з командного рядка.
Спочатку вийдіть з командного рядка PostgreSQL на мить, набравши:
Потім увійдіть до облікового запису postgres:
Ви можете створювати нові ролі з командного рядка за допомогою команди createuser. Використання прапора --interactive попросить вас ввести ім'я нової ролі і також запитає, чи мають у неї права суперкористувача.
Увійшовши до облікового запису postgres, Ви можете створити нового користувача, набравши:
Сценарій пропонуватиме вам кілька варіантів, і на основі ваших відповідей виконувати відповідні команди Postgres відповідно до ваших параметрів:
OutputEnter name of role to add: 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 на ці запити, ви створите користувача, аналогічного попередньому користувачеві.
Увійдіть назад до своєї оболонки psql Postgres:
Потім виконайте команду du , щоб побачити різницю між двома новими ролями. Ця команда починається з \, тому що це метакоманда psql, яку обробляє сам psql, а не PostgreSQL:
Output List roles Role name | Attributes | Member of -----------+------------------------------------ ------------------------+----------- demo_role | Cannot login | <> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <> test_user | | <>
Зверніть увагу, що користувач, створений із командного рядка, не має атрибута Cannot login .
Видалення ролей у PostgreSQL
Ви можете видалити роль, використовуючи наступний синтаксис:
Для демонстрації видаліть роль demo_role, набравши:
Якщо ви виконаєте команду для неіснуючого користувача, ви отримаєте повідомлення про помилку:
OutputERROR: role "demo_role" does not exist
Щоб уникнути цієї ситуації та зробити команду видалення користувача, якщо він існує, і мовчки нічого не робити, якщо користувача не існує, використовуйте наступний синтаксис:
З цією опцією команда успішно здійсниться незалежно від дійсності ролі. Спроба видалення demo_role з використанням вищезгаданих команд призведе до наступного:
OutputNOTICE: role "demo_role" не існує, skipping DROP ROLE
Визначення привілеїв під час створення ролі
Тепер ви готові відтворити роль demo_role із зміненими дозволами. Ви можете зробити це, вказавши бажані дозволи після основного оператора створення, наприклад:
Щоб побачити повний перелік опцій, введіть:
OutputCommand: CREATE ROLE Допис: define a new database role Syntax: CREATE ROLE name [ [ WITH ] option [ . ] ] where option can be: SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMIT connlimit | [ENCRYPTED] PASSWORD 'password' | PASSWORD NULL | VALID UNTIL 'timestamp' | IN ROLE role_name [, . ] | IN GROUP role_name [, . ] | ROLE role_name [, . ] | ADMIN role_name [, . ] | USER role_name [, . ] | SYSID uid URL: https://www.postgresql.org/docs/14/sql-createrole.html
Ви можете надати користувачеві demo_role можливість входу, набравши:
Перевіривши атрибути за допомогою команди \du можна переконатися, що у двох користувачів тепер ідентичні привілеї:
Output List roles Role name | Attributes | Member of -----------+------------------------------------ ------------------------+----------- demo_role | | <> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <> test_user | | <>
Ви можете досягти цього стану, не вказуючи атрибут LOGIN під час створення кожної ролі. Використовуючи наступну команду CREATE USER, автоматично надаються привілеї входу ролі:
Роль створюється з автоматично наданими привілеями.
Зміна привілеїв ролей у PostgreSQL
Для зміни атрибутів вже створеної ролі використовуйте команду ALTER ROLE. Синтаксис цієї команди наступний:
Ця команда дозволяє визначити зміни привілеїв без необхідності видаляти та заново створювати користувачів, як показано раніше. Наприклад, ви можете змінити demo_role назад на його попередній стан Неможливий вхід, виконавши цю команду:
Ви можете підтвердити зміну за допомогою команди \du:
Output List roles Role name | Attributes | Member of -----------+------------------------------------ ------------------------+----------- demo_role | Cannot login | <> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <> test_user | | <>
Щоб змінити його назад на доступ до входу, використовуйте таку команду:
Тепер роль було повернуто.
Вхід у систему під іншим користувачем у PostgreSQL
За промовчанням користувачам дозволено лише локальний вхід, якщо ім'я користувача системи збігається з ім'ям користувача PostgreSQL. Ви можете змінити це або змінивши тип входу, або вказавши, що PostgreSQL має використовувати інтерфейс мережі зворотного зв'язку. Це змінює тип підключення на віддалений, навіть якщо це фактично локальне підключення.
Спочатку створіть пароль для користувача, з яким ви хочете підключитися, щоб він міг проходити автентифікацію. Ви можете спробувати це з test_user, створеним раніше, задавши йому пароль:
Вам буде запропоновано ввести та підтвердити пароль. Тепер вийдіть з інтерфейсу PostgreSQL і поверніться до звичайного користувача за допомогою цієї команди:
PostgreSQL передбачає, що при вході в систему ви будете використовувати ім'я користувача, що збігається з ім'ям вашої операційної системи, і що ви підключатиметеся до бази даних з тим же ім'ям.
Щоб явно вказати опції, які потрібно використовувати, використовуйте наступний синтаксис з вашими параметрами:
Ось короткий опис кожного пункту в команді:
- user_name слід замінити ім'ям користувача, з яким потрібно підключитися.
- database_name має бути ім'ям існуючої бази даних, до якої ви маєте доступ.
- Розділ -h 127.0.0.1 – це частина, яка вказує, що ви підключатиметеся до локальної машини, але через мережевий інтерфейс, що дозволяє вам проходити автентифікацію, навіть якщо ваше ім'я користувача системи не збігається.
- Прапор -W повідомляє PostgreSQL, що ви вводитимете пароль.
Щоб увійти під користувачем test_user, виконайте таку команду:
Після цієї команди вам потрібно буде ввести пароль.
У цьому прикладі використовується база даних postgres. Це стандартна база даних, налаштована під час встановлення. Якщо ви спробуєте виконати деякі дії у цій сесії, ви побачите, що у вас немає можливості зробити багато. Це тому, що користувачеві test_user були надані адміністративні права.
Вийдіть із поточної сесії:
Потім поверніться до адміністративної сесії postgres:
Потім ви надаватимете дозволи.
Надання дозволів у PostgreSQL
Коли створюється база даних або таблиця, зазвичай дозвіл на її зміну має лише роль, яка її створила, за винятком ролей зі статусом суперкористувача. Цю поведінку можна змінити, надавши дозволи іншим ролям.
Ви можете надати дозволи, використовуючи команду GRANT із загальним синтаксисом:
Ви можете створити таблицю для практики цих концепцій за допомогою наступних команд:
Щоб переглянути створену таблицю, введіть цю команду:
Output List of relations Schema | Name | Тип | Owner --------+-------------+----------+---------- public | Демо | table | postgres public | demo_id_seq | sequence | postgres (2 rows)
Зверніть увагу, що є один тип table і один тип sequence . Послідовність генерується для вас, коли ви використовували команду id serial під час створення таблиці. Це генерує число, що автоматично збільшується.
Тепер ви можете надати деякі привілеї для нового demo таблиці для demo_role. Для цього дайте користувачеві demo_role дозволу UPDATE за допомогою наступної команди:
Ви можете надати повні дозволи користувачеві, замінивши тип дозволу слово ALL . Надайте цей дозвіл користувачеві test_user за допомогою цієї команди:
Якщо ви бажаєте вказати дозволи для кожного користувача в системі, ви можете використовувати PUBLIC замість конкретного користувача:
Щоб переглянути таблицю дозволів, використовуйте таку команду:
Output Access privileges Schema | Name | Тип | Access privileges | Column privileges | Policies --------+-------------+----------+--------------- -------------+-------------------+---------- public | Демо | table | postgres = arwdDxt / postgres + | | | | | demo_role=w/postgres +| | | | | test_user=arwdDxt/postgres+| | | | | = a/postgres | | public | demo_id_seq | sequence | | | (2 rows)
Це показує всі дозволи, призначені.
Видалення дозволів у PostgreSQL
Ви можете видалити дозволи за допомогою REVOKE . Команда REVOKE використовує практично той самий синтаксис, що і команда grant:
Ви також можете використовувати ті ж скорочення, ALL і PUBLIC , в команді:
Раніше встановлені вами дозволи відкликані.
Використання групових ролей у PostgreSQL
Ролі досить гнучкі, щоб дозволяти групувати інші ролі для забезпечення широкого контролю за дозволами. Наприклад, ви можете створити нову роль під назвою temporary_users і потім додати demo_role і test_user до цієї групи.
Спочатку створіть нову роль, яка буде використовуватися як група:
Потім призначте користувачів у щойно створену групу temporary_users:
Тепер ці два користувача можуть керувати своїми дозволами, керуючи груповою роллю temporary_usersзамість управління кожним учасником індивідуально.
Інформацію про членство в ролі можна переглянути, набравши:
OutputList roles Role name | Attributes | Member of -----------------+------------------------------ ------------------------------+------------------- demo_role | | postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | <>temporary_users | Cannot login | <> test_user | |
Будь-який член групи може діяти у ролі групи, якою є членом, використовуючи команду SET ROLE . Оскільки користувач postgres, під яким ви в даний час увійшли, має привілеї суперкористувача, ви можете використовувати команду SET ROLE , навіть якщо він не є членом групи temporary_users:
Тепер будь-які створені таблиці належать ролі temporary_users:
Тепер перевірте володіння таблицею, виконавши цю команду:
Output List of relations Schema | Name | Тип | Owner --------+--------------+----------+-------------- --- public | Демо | table | postgres public | demo_id_seq | sequence | postgres public | hello | table | temporary_users public | hello_id_seq | sequence | temporary_users (4 rows)
Нова таблиця та послідовність, пов'язана з типом даних serial, належать ролі temporary_users:
Щоб повернутися до вихідних дозволів ролі, виконайте наступну команду:
Якщо ви призначите користувачеві властивість INHERIT за допомогою команди ALTER ROLE, цей користувач автоматично отримає всі привілеї ролей, до яких він належить, без використання команди SET ROLE:
Тепер test_user матиме всі дозволи ролей, яких він належить. Ви можете видалити групову роль або будь-яку роль за допомогою команди DROP ROLE. Ви можете протестувати це з групою temporary_users, ввівши таку команду:
OutputERROR: role "temporary_users" не може бути скасована тому, що деякі об'єкти depend on it DETAIL: owner of sequence hello_id_seq
Це видасть помилку, тому що таблиця hello належить temporary_users. Проблему можна вирішити, передавши володіння іншою роллю:
Ви можете перевірити, чи не належить temporary_users більше ніяких таблиць за допомогою наступної команди:
Output List of relations Schema | Name | Тип | Owner --------+--------------+----------+----------- public | Демо | table | postgres public | demo_id_seq | sequence | postgres public | hello | table | demo_role public | hello_id_seq | sequence | demo_role (4 rows)
Тепер ви можете успішно видалити роль temporary_users за допомогою цієї команди:
Це знищить роль temporary_users. Колишні учасники temporary_users не видаляються.
Висновок
Тепер у вас є базові навички, необхідні для керування дозволами вашої бази даних PostgreSQL. Важливо знати, як керувати дозволами, щоб ваші програми могли отримувати доступ до необхідних баз даних, не порушуючи дані, що використовуються іншими програмами.
Якщо ви хочете дізнатися більше про Postgres і про те, як ним користуватися, ми запрошуємо вас ознайомитися з наступними посібниками:
