sql >> Database teknologi >  >> RDS >> PostgreSQL

En oversigt over betroede udvidelser i PostgreSQL 13

I min tidligere blog udforskede vi nye muligheder for logisk replikering med partitionstabeller i PostgreSQL 13. Det er overflødigt at sige, at der er mange af sådanne funktioner i den nævnte udgivelse, som snart vil forbedre oplevelsen for DBA og applikationer både udviklere.

Mens jeg så på PostgreSQL 13, observerede jeg et indlæg, der fangede min opmærksomhed:

PostgreSQL 13 introducerer konceptet med en "betroet udvidelse", som giver en superbruger mulighed for at specificere udvidelser, som en bruger kan installere i deres database, så længe de har et CREATE-privilegium.

Lad os spole tilbage

Vi ved, at PostgreSQL har forlængelseskraft til at tilføje fjer til dens hætte uden at forstyrre meget af dens kerne. Med andre ord forbedrer udvidelser funktionelle muligheder til PostgreSQL Server på en ikke-påtrængende måde.

Faktisk er der mange tredjepartsorganisationer, der har brugt udvidelsesmekanismer til at generere fantastiske funktionssæt. TimescaleDB er en sådan udvidelse, hvor den på en måde ændrer personligheden af ​​PostgreSQL Server for at gøre den mere egnet til IOT-arbejdsbelastning.

Lad os tage et kig på, hvad der var der før PostgreSQL 13, og hvorfor det var en rigtig smerte. Overvej en hostet PostgreSQL-instans, der indeholder to roller:

  • postgres (superbrugeren)
  • johnsmith (en normal bruger)

Og databasen wooliesdb.

John Smith vil gerne tilføje postgres-udvidelsen hstore til wooliedb, da hans applikationskode er afhængig af det. Lad os prøve at gøre det.

 psql -U johnsmith -d wooliesdb

wooliesdb=>CREATE EXTENSION hstore;

ERROR:  permission denied to create extension "hstore"

HINT:  Must be superuser to create this extension.

Fejlen indikerer tydeligt, at udvidelsen kun kan oprettes af superbruger, dvs. postgres. Selvom udvidelser som hstore ikke har nogen sikkerhedsproblemer i forbindelse med dets brug, er det stadig kun superbrugere, der kan oprette denne udvidelse på databasen.

Hvad nu hvis databasen var ejet eller oprettet af johnsmith - det kan vi også prøve. I det følgende uddrag tillader postgres superbruger johnsmith at oprette en helt ny database for sig selv at lege med:

$ 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.

Åhh! Det gør ingen forskel. Selvom johnsmith er ejer af jsDB, kan han stadig ikke installere relevante, simple udvidelser til sin database.

Men det er alt sammen i PostgreSQL server 12 (og derunder); det vil ændre sig med PostgreSQL version 13. På tidspunktet for skrivning af denne blog - PostgreSQL version 13 er i Beta2-stadiet, og holdet er allerede ved at skrive en udgivelsesmeddelelse. Jeg vil prøve "trusted extensions" med Beta2 binære filer.

Her kommer PostgreSQL 13

Forvent en anden adfærd med begrebet betroede udvidelser (i det mindste for bidragsmoduler eller færdigpakkede udvidelser). Lad os tjekke adfærden med PostgreSQL13 for de samme kommandoer, som vi gjorde for 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.

Hvilket er stort set det samme, dvs. johnsmith kan stadig ikke oprette udvidelsen. Men der er stadig en subtil forskel - HINT, der tyder på, at CREATE-privilegiet mangler. Vores andet sæt kommandoer bør tage sig af det:

$ 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)

Tingene fungerede virkelig denne gang. Superbruger kan tillade samme privilegier på postgres db ved at udføre følgende kommando:

postgres=# GRANT CREATE ON DATABASE postgres FOR johnsmith;

Men der er mere til betroet udvidelse end dette, lad os prøve at oprette en anden udvidelse:

jsDB=> create extension file_fdw;

ERROR:  permission denied to create extension "file_fdw"

HINT:  Must be superuser to create this extension.

Forskellen kommer fra det faktum, at mens hstore er markeret som betroet, er file_fdw IKKE markeret som betroet. Hvor er det markeret? Det er i kontrolfilen for udvidelserne.

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

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

hstore.control

Faktisk kommer der 24 betroede og 24 ikke så betroede udvidelser med postgreSQL13.

I en nøddeskal kan superbrugere give afkald på kontrol over sådanne betroede udvidelser; og enhver bruger med CREATE-tilladelserne på en database kan aktivere betroede udvidelser uden at henvende sig til sin databaseadministrator.

Konklusion

Bag kulisserne styres adfærden af ​​to parametre i udvidelseskontrolfilen:

  • superbruger, som som standard er sand
  • pålidelig, som som standard er falsk

En udvidelse kan kun oprettes af en ikke-superbruger, hvis begge er sande. Faktisk er en betroet udvidelse, at installations- eller opdateringsscriptet køres som bootstrap-superbrugeren, ikke som den kaldende bruger. Husk, at udvidelser kan være skrevet på et sprog, der i sig selv ikke er tillid til - derfor behovet.


  1. SQL Server Failover Cluster Installation -3

  2. Opsætning af fremmednøgler i phpMyAdmin?

  3. MySQL LIKE I()?

  4. Sådan bruges en ringdatastruktur i vinduesfunktioner