PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Преглед на доверените разширения в PostgreSQL 13

В предишния ми блог проучихме нови възможности за логическа репликация с таблици на дялове в PostgreSQL 13. Излишно е да казвам, че в споменатата версия има множество такива функции, които скоро ще подобрят опита за DBA и приложения разработчици.

Докато разглеждах PostgreSQL 13, забелязах запис, който привлече вниманието ми:

PostgreSQL 13 въвежда концепцията за "доверено разширение", което позволява на суперпотребител да указва разширения, които потребителят може да инсталира в своята база данни, стига да има привилегия CREATE.

Да превъртим назад

Знаем, че PostgreSQL има разширение, за да добавя пера към капачката си, без да нарушава голяма част от ядрото му. С други думи, разширенията подобряват функционалните възможности на PostgreSQL Server по ненатрапчив начин.

Всъщност има много организации на трети страни, които са използвали механизма за разширения, за да генерират невероятни набори от функции. TimescaleDB е едно такова разширение, при което променя характера на PostgreSQL Server, за да го направи по-подходящ за IOT работно натоварване.

Нека да разгледаме какво имаше преди PostgreSQL 13 и защо беше истинска болка. Помислете за хостван екземпляр на PostgreSQL, съдържащ две роли:

  • postgres (супер потребител)
  • johnsmith (обикновен потребител)

И базата данни wooliesdb.

Джон Смит би искал да добави разширението postgres hstore към wooliedb, тъй като кодът на приложението му разчита на това. Нека се опитаме да направим това.

 psql -U johnsmith -d wooliesdb

wooliesdb=>CREATE EXTENSION hstore;

ERROR:  permission denied to create extension "hstore"

HINT:  Must be superuser to create this extension.

Грешката ясно показва, че разширението може да бъде създадено само от супер потребител, т.е. postgres. Въпреки че разширенията като hstore нямат опасения за сигурността в контекста на тяхното използване, все още само супер потребители могат да създават това разширение в базата данни.

Ами ако базата данни е била собственост или създадена от johnsmith - можем да опитаме и това. В следния фрагмент суперпотребител на postgres позволява на johnsmith да създаде изцяло нова собствена база данни, с която да си играе:

$ psql -U postgres 

postgres=# ALTER ROLE johnsmith CREATEDB;

postgres=# \q

$ psql -U johnsmith -d wooliesdb

wooliesdb=>CREATE DATABASE jsDB;

wooliesdb=>\c jsDB;

You are now connected to database "jsDB" as user "johnsmith".

jsDB=>CREATE EXTENSION hstore;

ERROR:  permission denied to create extension "hstore"

HINT:  Must be superuser to create this extension.

Ааа! Това не прави никаква разлика. Въпреки че Johnsmith е собственик на jsDB,  той все още не може да инсталира подходящи прости разширения към своята база данни.

Но това е всичко в PostgreSQL сървър 12 (и по-долу); ще се промени с PostgreSQL версия 13. Към момента на писане на този блог - PostgreSQL версия 13 е в етап Beta2 и екипът вече пише съобщение за изданието. Ще опитам „доверени разширения“ с Beta2 двоични файлове.

Тук идва PostgreSQL 13

Очаквайте различно поведение с концепцията за доверени разширения (поне за модули за принос или предварително опаковани разширения). Нека проверим поведението с PostgreSQL13 за същите команди, които направихме за PostgreSQL12.

$ psql -U johnsmith -d wooliesdb

wooliesdb=>CREATE EXTENSION hstore;

ERROR:  permission denied to create extension "hstore"

HINT:  Must have CREATE privilege on current database to create this extension.

Което е почти същото, т.е. johnsmith все още не може да създаде разширението. Но все пак има фина разлика - НАМЕХът, който предполага, че липсва привилегията CREATE. Вторият ни набор от команди трябва да се погрижи за това:

$ psql -U postgres 

postgres=# ALTER ROLE johnsmith CREATEDB;

postgres=# \q

$ psql -U johnsmith -d wooliesdb

wooliesdb=>CREATE DATABASE jsDB;

wooliesdb=>\c jsDB;

You are now connected to database "jsDB" as user "johnsmith".

jsDB=>CREATE EXTENSION hstore;

jsDB=>SELECT extname from pg_extension;

 extname

---------

 plpgsql

 hstore

(2 rows)

Този път нещата наистина проработиха. Суперпотребителят може да разреши същите привилегии на postgres db, като изпълни следната команда:

postgres=# GRANT CREATE ON DATABASE postgres FOR johnsmith;

Но има повече доверено разширение от това, нека се опитаме да създадем друго разширение:

jsDB=> create extension file_fdw;

ERROR:  permission denied to create extension "file_fdw"

HINT:  Must be superuser to create this extension.

Разликата идва от факта, че докато hstore е маркиран като доверен, file_fdw НЕ е маркиран като доверен. Къде е отбелязано това? Той е в контролния файл на разширенията.

$ cd /usr/pgsql-13/share/extension 

$ grep -l trusted hstore.control file_fdw.control;

hstore.control

Всъщност има 24 доверени и 24 не толкова доверени разширения, идващи с postgreSQL13.

Накратко, суперпотребителите могат да се откажат от контрола върху такива доверени разширения; и всеки потребител с разрешения CREATE за база данни може да активира доверени разширения, без да се обръща към своя администратор на базата данни.

Заключение

Зад кулисите поведението се контролира от два параметъра в контролния файл на разширението:

  • суперпотребител, който по подразбиране е true
  • доверен, което по подразбиране е false

Разширение може да бъде създадено от не-суперпотребител само ако и двете са верни. Всъщност, доверено разширение е, че скриптът за инсталиране или актуализиране се изпълнява като началния суперпотребител, а не като потребител, който се обажда. Не забравяйте, че разширенията може да са написани на език, който сам по себе си не е надежден - оттук и необходимостта.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Добавете знак плюс/минус към число в PostgreSQL

  2. как да емулирам вмъкване игнориране и при актуализиране на дублиран ключ (sql обединяване) с postgresql?

  3. Как да възстановим данни от изтрит Docker контейнер? Как да го свържете отново с данните?

  4. postgresql - sql - брой "истински" стойности

  5. Продължаване на транзакция след грешка при нарушение на първичния ключ