sql >> Databasteknik >  >> RDS >> PostgreSQL

Hantera roller och rollattribut i PostgreSQL


Introduktion

PostgreSQL använder olika mekanismer för att implementera autentisering, auktorisering och objektägande inom databaskluster. Kärnan bland dessa är begreppet roller.

PostgreSQL-roller är en kombination av idéer från användare och grupper till en enda flexibel enhet. De är den persona som användaren antar inom databassystemet, är den enhet genom vilken autentiseringssystemet accepterar eller nekar anslutningar, och föremål för privilegiehanteringsregler av alla omfattningar.

Den här guiden kommer att täcka vad roller är och hur man hanterar dem inom ett PostgreSQL-databaskluster. Mer specifikt kommer den här guiden att täcka rollhantering när det gäller rollattribut. För en bredare översikt av hur roller passar in i den större bilden, ta en titt på introduktionen till autentiserings- och auktoriseringsguiden. För att lära dig hur du ändrar rollbehörigheter på specifika databasobjekt, kolla in vår guide om rollbeviljande.



Vad är roller?

I PostgreSQL är en roll en gruppering av en specifik uppsättning funktioner, behörigheter och "ägda" enheter. Istället för att ha distinkta begrepp som "användare" och "grupper" använder PostgreSQL roller för att representera båda dessa idéer. En roll kan motsvara en enskild person i den verkliga världen, eller så kan den fungera som en grupp med viss tillgång som andra roller kan bli medlemmar av.

Roller är ankarpunkten inom PostgreSQL som avgör vem autentiserings- och auktoriseringspolicyer gäller för. Varje policy som inte gäller universellt kräver en uppfattning om identitet för att definiera vem som ska begränsas och vem som ska tillåtas. I PostgreSQL representeras denna identitet av roller.

PostgreSQL:s autentiseringssystem har ett antal olika komponenter, som var och en är knuten till roller. För att kunna användas för den initiala anslutningen till databasklustret måste roller först ha LOGIN attributuppsättning. Själva autentiseringsreglerna definieras i den värdbaserade konfigurationsfilen som heter pg_hba.conf . Varje regel definierar autentiseringsmetoder som kan anpassas till den individuella rollen. För roller som är konfigurerade för lösenordsautentisering måste ett lösenordsattribut ställas in så att systemet kan validera det angivna användarlösenordet.

Vad gäller behörighet definieras roller på databasklusternivå, vilket i PostgreSQL innebär att de delas mellan databaser. Eftersom roller sträcker sig över databaser styr auktoriseringssystemet vilken åtkomstnivå varje roll har till varje databasenhet. Eftersom roller kan representera grupper av människor finns det en stor flexibilitet i hur åtkomst kan konfigureras.

Roller är också väsentliga för konceptet objektägande inom PostgreSQL. Varje databas och tabell, till exempel, har exakt en roll konfigurerad som ägare. Andra än superusers , är ägarrollen den enda rollen som kan ändra eller ta bort det faktiska objektet.

Sammanfattningsvis är roller kärnan i de flesta praktiska databasoperationer. Deras flexibilitet tillåter dem att fungera både som användaridentifierare och användarklasser. Varje åtgärd inom databasklustret kontrolleras mot rollens privilegier och framgången för varje anslutning till databasklustret bestäms av rollen man autentiserar till. Det är viktigt att få ett bra grepp om rollhantering på grund av dess betydelse inom så många kärnverksamheter.



Rollattribut

Rollattribut är flaggor på själva rollen som bestämmer några av de kärnprivilegier som den har på databasklusternivån. Dessa kan ställas in när rollen skapas från början, eller ändras när som helst av vilken roll som helst med lämpliga attribut (SUPERUSER eller CREATEROLE i det här fallet).

Attribut som kan tillämpas på en roll inkluderar:

  • LOGIN :Tillåter användare att initialt ansluta till databasklustret med den här rollen. CREATE USER kommandot lägger automatiskt till detta attribut, medan CREATE ROLE kommandot inte.
  • SUPERUSER :Tillåter rollen att kringgå alla behörighetskontroller förutom rätten att logga in. Endast andra SUPERUSER roller kan skapa roller med detta attribut.
  • CREATEDB :Tillåter rollen att skapa nya databaser.
  • CREATEROLE :Tillåter rollen att skapa, ändra och ta bort andra roller. Detta attribut tillåter också rollen att tilldela eller ändra rollmedlemskap. Ett undantag är att en roll med CREATEROLE attributet kan inte ändra SUPERUSER roller utan att också ha SUPERUSER attribut.
  • REPLICATION :Tillåter rollen att initiera strömmande replikering. Roller med detta attribut måste också ha LOGIN attribut.
  • PASSWORD :Tilldelar ett lösenord till rollen som ska användas med password eller md5 autentiseringsmekanismer. Detta attribut tar ett lösenord inom citattecken som ett argument direkt efter attributnyckelordet.
  • INHERIT :Avgör om rollen ärver privilegierna för roller den är medlem i. Utan INHERIT , medlemmar måste använda SET ROLE att byta till den andra rollen för att få tillgång till dessa exklusiva privilegier. Det här attributet är inställt för nya roller som standard.

Du kan ta reda på mer om rollattribut genom att kolla in PostgreSQL:s dokumentation om rollattribut och CREATE ROLE kommando.



Vad är en superuser roll?

Som nämnts kort ovan, ett speciellt privilegium som kallas superuser tillåter obegränsad administrativ åtkomst till databasklustret. Detta liknar root konto i Linux och Unix-liknande operativsystem, men på databasnivå.

Det måste alltid finnas minst en roll med superusers privilegier i varje databaskluster. Den första superuser konto skapas under installationsprocessen. Namnet på den initiala superuser kontot kan variera beroende på installationsprocessen, men oftast kallas detta konto för postgres .

Det rekommenderas inte att göra ditt dagliga arbete med ett konto med superusers privilegier, både på grund av dess potential för destruktiva handlingar och även för att minimera risken att äventyra ett konto med bred åtkomst. Istället bör användare oftast använda konton som är dedikerade till de specifika funktionerna eller dataobjekten de arbetar med, endast med superuser konton när mer kraftfull åtkomst krävs.



Kontrollera befintliga rollattribut

Nu när du har en bred uppfattning om vad rollattribut är och vilka typer av privilegier de tillåter, bör du lära dig hur du hittar de attribut som tillämpas på roller i PostgreSQL. Det här avsnittet kommer att visa dig några kommandon som hjälper dig att hitta attributen som är inställda på roller i allmänhet och för din egen nuvarande roll specifikt.


Lista alla databasroller och deras attribut

Det finns några olika sätt att kontrollera de attribut som tillämpas på roller i hela systemet.

Om du använder psql kommandoradsklient kan du dra fördel av några användbara metakommandon som låter dig få information om rollattribut utan en fråga.

\du meta-kommando visar alla roller och deras attribut:

\du
                                   List of roles Role name |                         Attributes                         | Member of-----------+------------------------------------------------------------+----------- postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

I det här fallet, postgres roll är standardrollen med superusers privilegier konfigurerade för detta databaskluster.

Motsvarande SQL till listroller (kan hittas genom att skicka -E eller --echo-hidden flagga när du startar psql ) är:

SELECT r.rolname, r.rolsuper, r.rolinherit,  r.rolcreaterole, r.rolcreatedb, r.rolcanlogin,  r.rolconnlimit, r.rolvaliduntil,  ARRAY(SELECT b.rolname        FROM pg_catalog.pg_auth_members m        JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid)        WHERE m.member = r.oid) as memberof, r.rolreplication, r.rolbypassrlsFROM pg_catalog.pg_roles rWHERE r.rolname !~ '^pg_'ORDER BY 1;

En liknande fråga som ger information om rollattribut (utan rollmedlemskapskomponenten) finns nedan. Vi använder psql metakommando \x on för att mata ut resultaten vertikalt för bättre läsbarhet här:

-- turn on vertical display\x onSELECT * FROM pg_roles WHERE rolname !~ '^pg_';-- turn off vertical display\x off
-[ RECORD 1 ]--+---------rolname        | postgresrolsuper       | trolinherit     | trolcreaterole  | trolcreatedb    | trolcanlogin    | trolreplication | trolconnlimit   | -1rolpassword    | ********rolvaliduntil  | rolbypassrls   | trolconfig      | oid            | 10

Om du bara är intresserad av att se vilka roller som har superuser attribut, kan du be om en lista uttryckligen:

SELECT rolname FROM pg_roles WHERE rolsuper;
 rolname---------- postgres(1 row)

Alternativt kan du lista alla användare och deras superusers status för en mer komplett bild:

SELECT usename,usesuper FROM pg_user;
 usename  | usesuper----------+---------- postgres | t user1    | f(2 rows)

Samma information kan hämtas med hjälp av PostgreSQL:s "roll"-paradigm istället för dess (ibland tvetydiga) "användar"-överlägg med denna lite längre fråga istället:

SELECT rolname,rolsuper FROM pg_roles WHERE rolname !~ '^pg_';
 rolname  | rolsuper----------+---------- postgres | t user1    | f(2 rows)


Lista dina egna attribut

Om du vill hitta attributen för rollen du för närvarande använder kan du enkelt filtrera utdata.

När du använder psql metakommandon kan du använda USER variabel, som kommer att ersättas med den aktuella anslutna rollen. psql använder kolon (: ) för att interpolera variabler:

\du :USER
                                   List of roles Role name |                         Attributes                         | Member of-----------+------------------------------------------------------------+----------- postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

För att få en lista som visar värdena för alla möjliga rollattribut kan du använda en fråga som jämför rollnamnet med värdet som returneras av CURRENT_ROLE PostgreSQL-funktion. Återigen, vi använder vertikal utdata för läsbarhet:

-- First, turn on vertical output\x onSELECT * FROM pg_roles WHERE rolename = CURRENT_ROLE;-- Change back to normal output\x off
-[ RECORD 1 ]--+---------rolname        | postgresrolsuper       | trolinherit     | trolcreaterole  | trolcreatedb    | trolcanlogin    | trolreplication | trolconnlimit   | -1rolpassword    | ********rolvaliduntil  |rolbypassrls   | trolconfig      |oid            | 10

För att bara kontrollera om din nuvarande roll har superusers privilegier kan du skriva:

SHOW is_superuser;
 is_superuser-------------- on(1 row)


Kontrollera om du har rollhanteringsprivilegier

För att skapa, ändra eller ta bort roller måste du antingen ha superusers eller CREATEROLE privilegier.

För att kontrollera vilka roller inom systemet som har rollhanteringsprivilegier, skriv:

SELECT rolname as "Users who can manage roles" FROM pg_roles WHERE rolsuper OR rolcreaterole;
 Users who can manage roles---------------------------- postgres(1 rows)

Om du bara vill veta om din nuvarande roll har rollhanteringsprivilegier kan du istället använda:

SELECT 'Yes' AS "Can I manage roles?" FROM pg_roles WHERE rolname = :'USER' AND (rolsuper OR rolcreaterole);
 Can I manage roles?--------------------- Yes(1 row)



Skapa roller

När du har verifierat att du har rollhanteringsprivilegier kan du börja skapa, ändra eller ta bort roller inom PostgreSQL.

Ett alternativ för att ställa in rollattribut är att deklarera dem när du skapar rollen. Detta gör att du kan ställa in startvillkoren för rollen, men du kan fortfarande ändra dem i efterhand om du vill ändra rollens åtkomstnivå. Du kan hitta mer information om CREATE ROLE kommando som vi kommer att använda för att bekanta dig med den grundläggande syntaxen.

Ett sätt att skapa en roll är från kommandoraden. PostgreSQL innehåller en createuser kommando som skapar en roll inom databasklustret med LOGIN privilegier.

Den allmänna syntaxen är:

createuser <options> <rolename>

Till exempel för att skapa en roll som heter admin med superusers privilegier när du ber om ett lösenord, kan du skriva:

createuser --superuser admin

Du skulle då kunna logga in med admin konto enligt autentiseringsmetoderna som beskrivs i pg_hba.conf fil.

För att skapa roller med SQL , den allmänna syntaxen ser ut så här:

CREATE ROLE <role>;

Attribut kan definieras genom att ange dem efter rollnamnet med WITH :

CREATE ROLE <role> WITH <options>;

Till exempel för att skapa en roll som heter user1 som kan logga in med lösenordet secretpassword , kan du skriva:

CREATE ROLE "user1" WITH LOGIN PASSWORD 'secretpassword';

För att istället skapa en roll med superuser privilegier (du måste också vara en superusers för att framgångsrikt utföra detta kommando) som inte kan logga in (användaren måste använda SET ROLE för att byta till den här rollen), kan du skriva:

CREATE ROLE "user2" WITH SUPERUSER;


Ändra befintliga roller

För att ändra attributen för befintliga roller kan du använda ALTER ROLE kommando istället. Precis som med rollskapande måste din nuvarande roll också ha antingen superusers eller CREATEROLE privilegier. Användare som inte har dessa privilegier kan bara använda ALTER ROLE kommando för att ändra sitt eget lösenord.

Genom att ändra roller kan du ändra de attribut som tilldelats en roll efter att den skapats. Samma attribut som nämns i avsnittet om rollskapande kan användas med ALTER ROLE syntax. En skillnad är att varje attributtyp kan negeras genom att lägga till NO prefix. Till exempel, för att tillåta en roll att logga in på databasklustret kan du ge den LOGIN attribut. För att ta bort den förmågan skulle du ändra rollen genom att ange NOLOGIN .

ALTER ROLE kommandot ändrar endast attributen är de som uttryckligen nämns. Med andra ord, ALTER ROLE kommandot anger ändringar till attribut, inte en fullständig uppsättning nya attribut.

För att tillåta user2 roll för att logga in på databasklustret kan du skriva:

ALTER ROLE "user2" WITH LOGIN;

Tänk på att även om detta möjliggör möjligheten att logga in, kontrolleras de tillåtna autentiseringsmetoderna fortfarande av pg_hba.conf fil.

Om du vill ha user2 för att kunna logga in, skapa roller och skapa databaser istället kan du ange dessa tre attribut, separerade med mellanslag:

ALTER ROLE "user2" WITH LOGIN CREATEROLE CREATEDB;

För att återkalla superusers status från en roll (du kan bara utföra detta kommando med en annan superusers roll), skriv:

ALTER ROLE "user2" WITH NOSUPERUSER;

För att ändra lösenordet för en roll kan du skriva följande (alla roller ska kunna utföra detta kommando på sin egen roll, oavsett CREATEROLE eller superusers privilegier):

ALTER ROLE <role> WITH PASSWORD '<password>';

Även om kommandot ovan fungerar, om möjligt, är det en bättre idé att använda psql metakommando för att ändra lösenord. psql kommandot frågar automatiskt efter ett lösenord och krypterar det innan det skickas till servern. Detta hjälper till att undvika att känsliga data läcker i loggar.

Du kan ändra en rolls lösenord med psql genom att skriva följande

-- To change your own password\password-- To change the password for another role\password <role>

Du kan också använda ALTER ROLE kommando för att byta namn på en roll:

ALTER ROLE <role> RENAME TO <newrole>

Tänk på att du inte kan byta namn på din nuvarande sessionsroll.



Ta bort roller

Att ta bort en befintlig roll följer ett liknande mönster som de tidigare kommandona. Återigen måste du ha CREATEROLE eller superusers privilegier för att utföra dessa kommandon.

En komplicerande faktor är att roller inte kan tas bort om de fortfarande refereras av objekt i databasen. Det betyder att du måste ta bort eller överföra äganderätten till alla objekt som rollen äger. Efteråt måste du också återkalla eventuella ytterligare privilegier rollen har på databasobjekt.

En detaljerad förklaring av hur man på lämpligt sätt omtilldelar och släpper privilegier tillhandahålls av Erwin Brandstetter på webbplatsen Database Administrators Stack Exchange. Samma process används nedan.

Först kan du tilldela alla rollens ägda objekt med hjälp av REASSIGNED OWNED kommando. Till exempel, om du förbereder att ta bort user2 roll, kan du tilldela dess objekt till postgres roll genom att skriva:

REASSIGN OWNED BY "user2" TO "postgres";

Nu ägs objekten av postgres , kan vi använda DROP OWNED kommando för att återkalla alla andra privilegier som vi har beviljats ​​för objekt. Detta kommando tar också bort alla objekt vi äger, men eftersom vi just har överfört dem till postgres rollen, user2 rollen har inte längre några ägda objekt. På grund av detta kommer kommandot endast att återkalla någon av rollens ytterligare privilegier:

DROP OWNED BY "user2";

Utan DROP OWNED genväg ovan, måste du köra REVOKE ALL PRIVILEGES på varje enskilt objekt eller objekttyp som rollen har privilegier för.

När du har återkallat alla associerade privilegier kan du ta bort rollen genom att skriva:

DROP ROLE "user2";


Logga in med psql

När du har konfigurerat en ny roll och har konfigurerat autentiseringsdetaljer med hjälp av pg_hba.conf fil kan du logga in på databasklustret med din nya roll. psql kommandoradsklienten ger ett enkelt sätt att göra detta.

Som standard, psql antar att du vill ansluta med en roll som matchar ditt operativsystems användarnamn. Så om du är inloggad på din dator som john , psql kommer att anta att du vill försöka ansluta till databasen med en roll som också kallas john .

För att åsidosätta detta beteende kan du skicka -U eller --username= alternativ. Till exempel, om du vill logga in på en roll som heter kerry , kan du skriva:

psql -U kerry

Framgången för psql kommandot beror på förekomsten av kerry roll, tillgängligheten för servern du försöker ansluta till och autentiseringsreglerna som definieras på servern.



Ändra till en annan roll under en session

Ibland kanske du vill tillfälligt anta privilegierna och identiteten för en annan roll som du har tillgång till. Detta är till exempel nödvändigt om du vill få privilegierna för en roll som du är medlem i om din nuvarande roll inte har INHERIT attribut.

För att förstå hur detta fungerar måste du känna till terminologin som PostgreSQL använder för att kategorisera aktiva roller:

  • Sessionsroll :En sessionsroll är den roll du loggade in med under din första anslutning till PostgreSQL-databasklustret. Den anger dina initiala privilegier och bestämmer din åtkomst till systemet. Den här rollen måste ha LOGIN attribut.
  • Nuvarande roll :Däremot är den nuvarande rollen den roll som du för närvarande agerar som. Behörigheterna som är kopplade till den aktuella rollen, oavsett om de är inställda direkt eller ärvda från andra roller, avgör vilka åtgärder du får utföra och vilka objekt du har åtkomst till.

Du kan se din session och aktuella rollvärden genom att skriva:

SELECT SESSION_USER, CURRENT_USER;
 current_user | session_user--------------+-------------- postgres     | postgres(1 row)

Även om det enda sättet att ändra din sessionsroll är att starta en ny anslutning med en annan roll, kan du ändra din nuvarande roll med SET ROLE kommando. SET ROLE kommandot används för att tillfälligt fungera som en annan roll. Kommandot tar även valfritt följande modifierare:

  • SESSION :Standardinställningen. Detta orsakar SET ROLE kommando för att påverka hela databassessionen.
  • LOCAL :Denna modifierare gör att kommandot ändrar rollen endast för aktuell transaktion.

För att ändra den aktuella rollen till user2 roll (för resten av sessionen), skriv:

SET ROLE "user2";

Om du kontrollerar din session och aktuella rollvärden kommer du att se att det aktuella rollvärdet har ändrats:

SELECT SESSION_USER, CURRENT_USER;
 current_user | session_user--------------+-------------- user2        | postgres(1 row)

Alla dina åtgärder kommer nu att använda user2 roll som deras sammanhang.

För att byta tillbaka till sessionsrollen du tidigare använt kan du skriva:

SET ROLE NONE;

Ett alternativ som ger samma resultat är:

RESET ROLE;


Slutsats

PostgreSQL:s system med roller, rollattribut, anslag och autentisering skapar ett flexibelt system som tillåter administratörer att effektivt hantera behörigheter och databasåtkomst. Den här guiden beskrev exakt vad roller är och hur de omfattar ett brett spektrum av användningsfall. Den behandlade också hur man skapar, ändrar och tar bort roller och hanterar rollattribut som bestämmer deras globala kapacitet. Att förstå hur man hanterar dessa identiteter är nödvändigt för att säkra dina databaser och ge användbar åtkomst till dina legitima användare.




  1. SQL Server delar upp CSV i flera rader

  2. Återställ din WordPress-databas med WP-CLI

  3. JSON_OBJECTAGG() Funktion i Oracle

  4. Android SQLiteOpenHelper:Varför kallas inte metoden onCreate()?