DCL Postgresql.pdf

8/12/2019 DCL Postgresql.pdf

1/26

Aspectos del DCL en Postgresql

Chapter 18. Database Roles and Privileges

PostgreSQL manages database access permissions using the concept of roles. A role can be thoughtof as either a database user, or a group of database users, depending on how the role is set up. Roles

can own database objects (for example, tables and can assign pri!ileges on those objects to other

roles to control who has access to which objects. "urthermore, it is possible to grant membership ina role to another role, thus allowing the member role use of pri!ileges assigned to the role it is a

member of.

#he concept of roles subsumes the concepts of $users% and $groups%. &n PostgreSQL !ersions

before '., users and groups were distinct )inds of entities, but now there are onl* roles. An* rolecan act as a user, a group, or both.

#his chapter describes how to create and manage roles and introduces the pri!ilege s*stem. +oreinformation about the !arious t*pes of database objects and the effects of pri!ileges can be found in

hapter -.

18.1. Database Roles

atabase roles are conceptuall* completel* separate from operating s*stem users. &n practice itmight be con!enient to maintain a correspondence, but this is not re/uired. atabase roles are

global across a database cluster installation (and not per indi!idual database. #o create a role usethe R0A#0 R1L0 SQL command2

R0A#0 R1L0 name3

name follows the rules for SQL identifiers2 either unadorned without special characters, or double4/uoted. (&n practice, *ou will usuall* want to add additional options, such as L15&6, to the

command. +ore details appear below. #o remo!e an existing role, use the analogous R1P R1L0command2

R1P R1L0 name3

"or con!enience, the programs createuser and dropuser are pro!ided as wrappers around these SQLcommands that can be called from the shell command line2

createuser name

dropuser name

#o determine the set of existing roles, examine the pg7roles s*stem catalog, for example

SELECT rolname R!" pg#roles$

#he ps/l program8s%d&meta4command is also &se'&l 'or listing the e(isting roles.


2/26


3/26

role with R0A#0R1L0 pri!ilege can alter and drop other roles, too, as well as grant or re!o)e

membership in them. ?owe!er, to create, alter, drop, or change membership of a superuser role,superuser status is re/uired3 R0A#0R1L0 is not sufficient for that.

pass*ord

A password is onl* significant if the client authentication method re/uires the user to suppl* apassword when connecting to the database. #he password, md-, and cr*pt authentication methods

ma)e use of passwords. atabase passwords are separate from operating s*stem passwords. Specif*

a password upon role creation with R0A#0 R1L0 name PASS@1R 8string 8.

A role8s attributes can be modified after creation with AL#0R R1L0. See the reference pages forthe R0A#0 R1L0 and AL#0R R1L0 commands for details.

#ip2 &t is good practice to create a role that has the R0A#0> and R0A#0R1L0 pri!ileges, butis not a superuser, and then use this role for all routine management of databases and roles. #his

approach a!oids the dangers of operating as a superuser for tas)s that do not reall* re/uire it.

A role can also ha!e role4specific defaults for man* of the run4time configuration settings described

in hapter . "or example, if for some reason *ou want to disable index scans (hint2 not a goodidea an*time *ou connect, *ou can use AL#0R R1L0 m*name S0# enable7indexscan #1 off3

#his will sa!e the setting (but not set it immediatel*. &n subse/uent connections b* this role it willappear as though S0# enable7indexscan #1 off3 had been executed just before the session started.

=ou can still alter this setting during the session3 it will onl* be the default. #o remo!e a role4

specific default setting, use AL#0R R1L0 rolename R0S0# !arname3. 6ote that role4specificdefaults attached to roles without L15&6 pri!ilege are fairl* useless, since the* will ne!er be

in!o)ed.

18.+. Privileges

@hen an object is created, it is assigned an owner. #he owner is normall* the role that executed thecreation statement. "or most )inds of objects, the initial state is that onl* the owner (or a superuser

can do an*thing with the object. #o allow other roles to use it, pri!ileges must be granted. #here are

se!eral different )inds of pri!ilege2 S0L0#, &6S0R#, :PA#0, 0L0#0, R:L0,R0"0R060S, #R&550R, R0A#0, #0+P1RAR=, 0B0:#0, and :SA50. "or more

information on the different t*pes of pri!ileges supported b* PostgreSQL, see the 5RA6#reference page.

#o assign pri!ileges, the 5RA6# command is used. So, if joe is an existing role, and accounts is anexisting table, the pri!ilege to update the table can be granted with

5RA6# :PA#0 16 accounts #1 joe3

#he special name P,-LCcan be used to grant a pri!ilege to e!er* role on the s*stem. @ritingALL in place of a specific pri!ilege specifies that all pri!ileges that appl* to the object will be

granted.

#o re!o)e a pri!ilege, use the fittingl* named R0C1D0 command2

R0C1D0 ALL 16 accounts "R1+ P:>L&3


4/26

#he special pri!ileges of an object8s owner (i.e., the right to modif* or destro* the object are

alwa*s implicit in being the owner, and cannot be granted or re!o)ed. >ut the owner can choose tore!o)e his own ordinar* pri!ileges, for example to ma)e a table read4onl* for himself as well as

others.

An object can be assigned to a new owner with an AL#0R command of the appropriate )ind for theobject.

Superusers can alwa*s do this3 ordinar* roles can onl* do it if the* are both the current owner of theobject (or a member of the owning role and a member of the new owning role.


5/26

18./. Role "embership

&t is fre/uentl* con!enient to group users together to ease management of pri!ileges2 that wa*,

pri!ileges can be granted to, or re!o)ed from, a group as a whole. &n PostgreSQL this is done b*creating a role that represents the group, and then granting membership in the group role to

indi!idual user roles.#o set up a group role, first create the role2

R0A#0 R1L0 name3

#*picall* a role being used as a group would not ha!e the L15&6 attribute, though *ou can set it if*ou wish.

1nce the group role exists, *ou can add and remo!e members using the 5RA6# and R0C1D0

commands2

0RAT gro&p#role T! role12 ... $

RE3!4E gro&p#role R!" role12 ... $

=ou can grant membership to other group roles, too (since there isn8t reall* an* distinction betweengroup roles and non4group roles. #he database will not let *ou set up circular membership loops.

Also, it is not permitted to grant membership in a role to P,-LC.

The members o' a role can &se the privileges o' the gro&p role in t*o *a5s. irst2 ever5member o' a gro&p can e(plicitl5 do SET R!LE to temporaril5 6become7 the gro&p role. nthis state2 the database session has access to the privileges o' the gro&p role rather than theoriginal login role2 and an5 database obects created are considered o*ned b5 the gro&p rolenot the login role. Second2 member roles that have the 9ERT attrib&te a&tomaticall5 have&se o' privileges o' roles the5 are members o'.As an example, suppose we ha!e done

CREATE R!LE oe L!0 9ERT$CREATE R!LE admin !9ERT$CREATE R!LE *heel !9ERT$0RAT admin T! oe$0RAT *heel T! admin$

&mmediatel* after connecting as role joe, a database session will ha!e use of pri!ileges granted

directl5to joe pl&san* pri!ileges granted to admin, because joe $inherits% admin:s privileges.

?owe!er, pri!ileges granted to wheel are not a!ailable, because e!en though joe is indirectl* amember of wheel, the membership is !ia admin which has the 61&6?0R attribute. After

SET R!LE admin$

the session would ha!e use of onl* those pri!ileges granted to admin, and not those granted to joe.

After

SET R!LE *heel$

the session would ha!e use of onl* those pri!ileges granted to wheel, and not those granted to either

joe or admin. #he original privilege state can be restored *ith an5 o'

SET R!LE oe$


6/26

SET R!LE !E$RESET R!LE$

ote; The SET R!LE command al*a5s allo*s selecting an5 role that the original login role isdirectl5 or indirectl5 a member o'. Th&s2 in the above e(ample2 it is not necessar5 to becomeadmin be'ore becoming *heel.

6ote2 &n the SQL standard, there is a clear distinction between users and roles, and users do not

automaticall* inherit pri!ileges while roles do. #his beha!ior can be obtained in PostgreSQL b*

gi!ing roles being used as SQL roles the &6?0R attribute, while gi!ing roles being used as SQLusers the 61&6?0R attribute. ?owe!er, PostgreSQL defaults to gi!ing all roles the &6?0R

attribute, for bac)wards compatibilit* with pre4'. releases in which users alwa*s had use ofpermissions granted to groups the* were members of.

#he role attributes L15&6, S:P0R:S0R, R0A#0>, and R0A#0R1L0 can be thought of asspecial pri!ileges, but the* are ne!er inherited as ordinar* pri!ileges on database objects are. =ou

must actuall* S0# R1L0 to a specific role ha!ing one of these attributes in order to ma)e use of the

attribute. ontinuing the abo!e example, we might well choose to grant R0A#0> andR0A#0R1L0 to the admin role. #hen a session connecting as role joe would not ha!e these

pri!ileges immediatel*, onl* after doing

S0# R1L0 admin.

#o destro* a group role, use R1P R1L02

R1P R1L0 name3

An* memberships in the group role are automaticall* re!o)ed (but the member roles are not

otherwise affected. 6ote howe!er that an* objects owned b* the group role must first be dropped

or reassigned to other owners3 and an* permissions granted to the group role must be re!o)ed.


7/26

CREATE 3E = TE"P ? TE"P!RAR@ > 3E B >AS q&er5

escription

R0A#0 C&0@ defines a !iew of a /uer*. #he !iew is not ph*sicall* materiali9ed. &nstead, the

/uer* is run e!er* time the !iew is referenced in a /uer*.

R0A#0 1R R0PLA0 C&0@ is similar, but if a !iew of the same name alread* exists, it is

replaced. =ou can onl* replace a !iew with a new /uer* that generates the identical set of columns(i.e., same column names and data t*pes.

&f a schema name is gi!en (for example, R0A#0 C&0@ m*schema.m*!iew ... then the !iew is

created in the specified schema. 1therwise it is created in the current schema. #emporar* !iewsexist in a special schema, so a schema name ma* not be gi!en when creating a temporar* !iew. #he

name of the !iew must be distinct from the name of an* other !iew, table, se/uence, or index in the

same schema.

Parameters

#0+P1RAR= or #0+P

&f specified, the !iew is created as a temporar* !iew. #emporar* !iews are automaticall* dropped at

the end of the current session. 0xisting permanent relations with the same name are not !isible tothe current session while the temporar* !iew exists, unless the* are referenced with schema4

/ualified names.

&f an* of the tables referenced b* the !iew are temporar*, the !iew is created as a temporar* !iew

(whether #0+P1RAR= is specified or not.

name

#he name (optionall* schema4/ualified of a !iew to be created.

column7name

An optional list of names to be used for columns of the !iew. &f not gi!en, the column names arededuced from the /uer*. /uer*

A /uer* (that is, a S0L0# statement which will pro!ide the columns and rows of the !iew.

Referto S0L0# for more information about !alid /ueries.6otes

urrentl*, !iews are read onl*2 the s*stem will not allow an insert, update, or delete on a !iew. =ou


8/26

can get the effect of an updatable !iew b* creating rules that rewrite inserts, etc. on the !iew into

appropriate actions on other tables. "or more information see R0A#0 R:L0.

:se the R1P C&0@ statement to drop !iews.

>e careful that the names and t*pes of the !iew8s columns will be assigned the wa* *ou want. "or

example,

R0A#0 C&0@ !ista AS S0L0# 8?ello @orld83

is bad form in two wa*s2 the column name defaults to FcolumnF, and the column data t*pe defaults

to un)nown. &f *ou want a string literal in a !iew8s result, use something li)e

R0A#0 C&0@ !ista AS S0L0# text 8?ello @orld8 AS hello3

Access to tables referenced in the !iew is determined b* permissions of the !iew owner. ?owe!er,

functions called in the !iew are treated the same as if the* had been called directl* from the /uer*

using the !iew. #herefore the user of a !iew must ha!e permissions to call all functions used b* the!iew.

E(amples

reate a !iew consisting of all comed* films2

R0A#0 C&0@ comedies ASS0L0# G

"R1+ films@?0R0 )ind H 8omed*83

ompatibilit*#he SQL standard specifies some additional capabilities for the R0A#0 C&0@ statement2

R0A#0 C&0@ name I ( column7name I, ...J J

AS /uer*

I @? I ASA0 K L1AL J ?0D 1P#&16 J

#he optional clauses for the full SQL command are2

?0D 1P#&16

#his option has to do with updatable !iews. All &6S0R# and :PA#0 commands on the !iew will

be chec)ed to ensure data satisf* the !iew4defining condition (that is, the new data would be !isiblethrough the !iew. &f the* do not, the update will be rejected.

L1ALhec) for integrit* on this !iew.

ASA0

hec) for integrit* on this !iew and on an* dependent !iew. ASA0 is assumed if neither

ASA0 nor L1AL is specified.

R0A#0 1R R0PLA0 C&0@ is a PostgreSQL language extension. So is the concept of a


9/26

temporar* !iew.

See AlsoR1P C&0@


10/26

CREATE R!LE6ame

R0A#0 R1L0 E define a new database roleS*nopsis

CREATE R!LE name = = option = ... > >

where option can be2K K

S,PER,SER ? !S,PER,SERCREATED- ? !CREATED-CREATER!LE ? !CREATER!LECREATE,SER ? !CREATE,SER9ERT ? !9ERTL!0 ? !L!0C!ECT! L"T connlimit= ECR@PTED ? ,ECR@PTED > PASS

R!LE rolename =2 ...> 0R!,P rolename =2 ...>R!LE rolename =2 ...>AD" rolename =2 ...>,SER rolename =2 ...>S@SD &id

escription

R0A#0 R1L0 adds a new role to a PostgreSQL database cluster. A role is an entit* that can owndatabase objects and ha!e database pri!ileges3 a role can be considered a $user%, a $group%, or both

depending on how it is used. Refer to hapter ' and hapter ;< for information about managing

users and authentication. =ou must ha!e R0A#0R1L0 pri!ilege or be a database superuser to usethis command.

6ote that roles are defined at the database cluster le!el, and so are !alid in all databases in the

cluster.

Parameters

name

#he name of the new role.

S:P0R:S0R61S:P0R:S0R

#hese clauses determine whether the new role is a $superuser%, who can o!erride all accessrestrictions within the database. Superuser status is dangerous and should be used onl* when reall*

needed.

=ou must *ourself be a superuser to create a new superuser. &f not specified, 61S:P0R:S0R is

the default.


11/26


12/26

06R=P#0:606R=P#0

#hese )e* words control whether the password is stored encr*pted in the s*stem catalogs. (&f

neither is specified, the default beha!ior is determined b* the configuration parameterpassword7encr*ption.

&f the presented password string is alread* in +-4encr*pted format, then it is stored encr*pted as

is, regardless of whether 06R=P#0 or :606R=P#0 is specified (since the s*stem cannot

decr*pt the specified encr*pted password string. #his allows reloading of encr*pted passwordsduring dumpMrestore.

6ote that older clients ma* lac) support for the +- authentication mechanism that is needed to

wor) with passwords that are stored encr*pted.

CAL& :6#&L 8timestamp8

#he CAL& :6#&L clause sets a date and time after which the role8s password is no longer !alid. &fthis clause is omitted the password will be !alid for all time.

&6 R1L0 rolename

#he &6 R1L0 clause lists one or more existing roles to which the new role will be immediatel*

added as a new member. (6ote that there is no option to add the new role as an administrator3 use a

separate 5RA6# command to do that.

&6 5R1:P rolename

&6 5R1:P is an obsolete spelling of &6 R1L0.

R1L0 rolename

#he R1L0 clause lists one or more existing roles which are automaticall* added as members of the

new role. (#his in effect ma)es the new role a $group%.

A+&6 rolename

#he A+&6 clause is li)e R1L0, but the named roles are added to the new role @? A+&6

1P#&16, gi!ing them the right to grant membership in this role to others.

:S0R rolename

#he :S0R clause is an obsolete spelling of the R1L0 clause.

S=S& uid

#he S=S& clause is ignored, but is accepted for bac)wards compatibilit*.6otes :se AL#0R R1L0 to change the attributes of a role, and R1P R1L0 to remo!e a role. All

the attributes specified b* R0A#0 R1L0 can be modified b* later AL#0R R1L0 commands.

#he preferred wa* to add and remo!e members of roles that are being used as groups is to use

5RA6# and R0C1D0.


13/26

#he CAL& :6#&L clause defines an expiration time for a password onl*, not for the role per se. &n

particular, the expiration time is not enforced when logging in using a non4password4basedauthentication method.

#he &6?0R attribute go!erns inheritance of grantable pri!ileges (that is, access pri!ileges fordatabase objects and role memberships. &t does not appl* to the special role attributes set b*

R0A#0 R1L0 and AL#0R R1L0. "or example, being a member of a role with R0A#0>pri!ilege does not immediatel* grant the abilit* to create databases, e!en if &6?0R is set3 it

would be necessar* to become that role !ia S0# R1L0 before creating a database.

#he &6?0R attribute is the default for reasons of bac)wards compatibilit*2 in prior releases of

PostgreSQL, users alwa*s had access to all pri!ileges of groups the* were members of. ?owe!er,61&6?0R pro!ides a closer match to the semantics specified in the SQL standard.

>e careful with the R0A#0R1L0 pri!ilege. #here is no concept of inheritance for the pri!ilegesof a R0A#0R1L04role. #hat means that e!en if a role does not ha!e a certain pri!ilege but is

allowed to create other roles, it can easil* create another role with different pri!ileges than its own

(except for creating roles with superuser pri!ileges. "or example, if the role $user% has theR0A#0R1L0 pri!ilege but not the R0A#0> pri!ilege, nonetheless it can create a new role

with the R0A#0> pri!ilege. #herefore, regard roles that ha!e the R0A#0R1L0 pri!ilege asalmost4superuser4roles.

PostgreSQL includes a program createuser that has the same functionalit* as R0A#0 R1L0 (in

fact, it calls this command but can be run from the command shell.

#he 1660#&16 L&+ option is onl* enforced approximatel*3 if two new sessions start at

about the same time when just one connection $slot% remains for the role, it is possible that bothwill fail. Also, the limit is ne!er enforced for superusers.

E(amples

reate a role that can log in, but don8t gi!e it a password2

CREATE R!LE onathan L!0$

reate a role with a password2

CREATE ,SER davide (R0A#0 :S0R is the same as R0A#0 R1L0 except that it implies L15&6.reate a role with a password that is !alid until the end of ;ompatibilit*#he R0A#0 R1L0 statement is in the SQL standard, but the standard onl* re/uires the s*ntax

R0A#0 R1L0 name I @? A+&6 rolename J


14/26

+ultiple initial administrators, and all the other options of R0A#0 R1L0, are PostgreSQL

extensions.

#he SQL standard defines the concepts of users and roles, but it regards them as distinct concepts

and lea!es all commands defining users to be specified b* each database implementation. &nPostgreSQL we ha!e chosen to unif* users and roles into a single )ind of entit*. Roles therefore

ha!e man* more optional attributes than the* do in the standard.

#he beha!ior specified b* the SQL standard is most closel* approximated b* gi!ing users the

61&6?0R attribute, while roles are gi!en the &6?0R attribute.See Also

S0# R1L0, AL#0R R1L0, R1P R1L0, 5RA6#, R0C1D0, createuser


15/26

0RAT6ame

5RA6# E define access pri!ilegesS*nopsis

0RAT F F SELECT ? SERT ? ,PDATE ? DELETE ? R,LE ? REERECES ? TR00ER G=2...> ? ALL = PR3LE0ES > G! = TA-LE > tablename =2 ...>T! F &sername ? 0R!,P gro&pname ? P,-LC G =2 ...> =

0RAT F F CREATE ? TE"P!RAR@ ? TE"P G =2...> ? ALL = PR3LE0ES > G! DATA-ASE dbname =2 ...>T! F &sername ? 0R!,P gro&pname ? P,-LC G =2 ...> =

5RA6# O 0B0:#0 K ALL I PR&C&L050S J

16 ":6#&16 funcname ( I I argmode J I argname J argt*pe I, ...J J I, ...J#1 O username K 5R1:P groupname K P:>L& I, ...J I @? 5RA6# 1P#&16 J5RA6# O :SA50 K ALL I PR&C&L050S J

16 LA65:A50 langname I, ...J#1 O username K 5R1:P groupname K P:>L& I, ...J I @? 5RA6# 1P#&16 J

5RA6# O O R0A#0 K :SA50 I,...J K ALL I PR&C&L050S J

16 S?0+A schemaname I, ...J#1 O username K 5R1:P groupname K P:>L& I, ...J I @? 5RA6# 1P#&16 J

5RA6# O R0A#0 K ALL I PR&C&L050S J 16 #A>L0SPA0 tablespacename I, ...J

#1 O username K 5R1:P groupname K P:>L& I, ...J I @? 5RA6# 1P#&16 J

0RAT role =2 ...> T! &sername =2 ...> =


16/26

0RAT on Database !bects

#his !ariant of the 5RA6# command gi!es specific pri!ileges on a database object to one or more

roles.#hese pri!ileges are added to those alread* granted, if an*.

#he )e* word P:>L& indicates that the pri!ileges are to be granted to all roles, including thosethat ma* be created later. P:>L& ma* be thought of as an implicitl* defined group that alwa*s

includes all roles.

An* particular role will ha!e the sum of pri!ileges granted directl* to it, pri!ileges granted to an*

role it is presentl* a member of, and pri!ileges granted to P:>L&.

&f @? 5RA6# 1P#&16 is specified, the recipient of the pri!ilege ma* in turn grant it to others.@ithout a grant option, the recipient cannot do that. 5rant options cannot be granted to P:>L&.

#here is no need to grant pri!ileges to the owner of an object (usuall* the user that created it, as theowner has all pri!ileges b* default. (#he owner could, howe!er, choose to re!o)e some of his own

pri!ileges for safet*. #he right to drop an object, or to alter its definition in an* wa* is notdescribed b* a grantable pri!ilege3 it is inherent in the owner, and cannot be granted or re!o)ed.

#he owner implicitl* has all grant options for the object, too.

epending on the t*pe of object, the initial default pri!ileges ma* include granting some pri!ileges

to P:>L&. #he default is no public access for tables, schemas, and tablespaces3 #0+P tablecreation pri!ilege for databases3 0B0:#0 pri!ilege for functions3 and :SA50 pri!ilege for

languages. #he object owner ma* of course re!o)e these pri!ileges. ("or maximum securit*, issue

the R0C1D0 in the same transaction that creates the object3 then there is no window in whichanother user ma* use the object.

#he possible pri!ileges are2

S0L0#

Allows S0L0# from an* column of the specified table, !iew, or se/uence. Also allows the use of1P= #1. "or se/uences, this pri!ilege also allows the use of the curr!al function.

&6S0R#

Allows &6S0R# of a new row into the specified table. Also allows 1P= "R1+.

:PA#0

Allows :PA#0 of an* column of the specified table. S0L0# ... "1R :PA#0 and S0L0# ...

"1R S?AR0 also re/uire this pri!ilege (besides the S0L0# pri!ilege. "or se/uences, this

pri!ilege allows the use of the next!al and set!al functions.

0L0#0

Allows 0L0#0 of a row from the specified table.

R:L0


17/26

Allows the creation of a rule on the tableM!iew. (See the R0A#0 R:L0 statement.

R0"0R060S

#o create a foreign )e* constraint, it is necessar* to ha!e this pri!ilege on both the referencing andreferenced tables.

#R&550R

Allows the creation of a trigger on the specified table. (See the R0A#0 #R&550R statement.

R0A#0

"or databases, allows new schemas to be created within the database.

"or schemas, allows new objects to be created within the schema. #o rename an existing object, *ou

must own the object and ha!e this pri!ilege for the containing schema.

"or tablespaces, allows tables and indexes to be created within the tablespace, and allows databases

to be created that ha!e the tablespace as their default tablespace. (6ote that re!o)ing this pri!ilegewill not alter the placement of existing objects.

#0+P1RAR=

#0+P

Allows temporar* tables to be created while using the database.

0B0:#0

Allows the use of the specified function and the use of an* operators that are implemented on top of

the function. #his is the onl* t*pe of pri!ilege that is applicable to functions. (#his s*ntax wor)s for

aggregate functions, as well.

:SA50

"or procedural languages, allows the use of the specified language for the creation of functions in

that language. #his is the onl* t*pe of pri!ilege that is applicable to procedural languages.

"or schemas, allows access to objects contained in the specified schema (assuming that the objects8own pri!ilege re/uirements are also met. 0ssentiall* this allows the grantee to $loo) up% objects

within the schema.

ALL PR&C&L050S

5rant all of the a!ailable pri!ileges at once. #he PR&C&L050S )e* word is optional in PostgreSQL,

though it is re/uired b* strict SQL.

#he pri!ileges re/uired b* other commands are listed on the reference page of the respecti!ecommand.


18/26

0RAT on Roles

#his !ariant of the 5RA6# command grants membership in a role to one or more other roles.+embership in a role is significant because it con!e*s the pri!ileges granted to a role to each of its

members.&f @? A+&6 1P#&16 is specified, the member ma* in turn grant membership in the role to

others, and re!o)e membership in the role as well. @ithout the admin option, ordinar* users cannot

do that. ?owe!er, database superusers can grant or re!o)e membership in an* role to an*one. Rolesha!ing R0A#0R1L0 pri!ilege can grant or re!o)e membership in an* role that is not a superuser.

:nli)e the case with pri!ileges, membership in a role cannot be granted to P:>L&. 6ote also thatthis form of the command does not allow the noise word 5R1:P.

6otes#he R0C1D0 command is used to re!o)e access pri!ileges.

@hen a non4owner of an object attempts to 5RA6# pri!ileges on the object, the command will fail

outright if the user has no pri!ileges whatsoe!er on the object. As long as some pri!ilege isa!ailable, the command will proceed, but it will grant onl* those pri!ileges for which the user hasgrant options. #he 5RA6# ALL PR&C&L050S forms will issue a warning message if no grant

options are held, while the other forms will issue a warning if grant options for an* of the pri!ilegesspecificall* named in the command are not held.

(&n principle these statements appl* to the object owner as well, but since the owner is alwa*streated as holding all grant options, the cases can ne!er occur.

&t should be noted that database superusers can access all objects regardless of object pri!ilege

settings.

#his is comparable to the rights of root in a :nix s*stem. As with root, it8s unwise to operate as a

superuser except when absolutel* necessar*.

&f a superuser chooses to issue a 5RA6# or R0C1D0 command, the command is performed as

though it were issued b* the owner of the affected object. &n particular, pri!ileges granted !ia such acommand will appear to ha!e been granted b* the object owner. ("or role membership, the

membership appears to ha!e been granted b* the containing role itself.

5RA6# and R0C1D0 can also be done b* a role that is not the owner of the affected object, but is

a member of the role that owns the object, or is a member of a role that holds pri!ileges @?

5RA6# 1P#&16 on the object. &n this case the pri!ileges will be recorded as ha!ing been grantedb* the role that actuall* owns the object or holds the pri!ileges @? 5RA6# 1P#&16. "orexample, if table t is owned b* role g, of which role u is a member, then u can grant pri!ileges

on t to u;, but those pri!ileges will appear to ha!e been granted directl* b* g. An* other member

of role g could re!o)e them later.

&f the role executing 5RA6# holds the re/uired pri!ileges indirectl* !ia more than one role

membership path, it is unspecified which containing role will be recorded as ha!ing done the grant.&n such cases it is best practice to use S0# R1L0 to become the specific role *ou want to do the

5RA6# as. urrentl*, PostgreSQL does not support granting or re!o)ing pri!ileges for indi!idualcolumns of a table.

1ne possible wor)around is to create a !iew ha!ing just the desired columns and then grantpri!ileges to that !iew.


19/26

,se psql:s %H command to obtain in'ormation abo&t e(isting privileges2 'or e(ample;IJ %H m5tableAccess pri!ileges for database lusitania

Schema K 6ame K #*pe K

Access pri!ileges444444444444444444444444444444444444444444444444444444444444444444444444444444444444

public K m*table K table K OmiriamHarwdRxtMmiriam,HrMmiriam,group todosHarwMmiriam( row

#he entries shown b* 9 are interpreted thus2

Hxxxx 44 pri!ileges granted to P:>L&unameHxxxx 44 pri!ileges granted to a user

group gnameHxxxx 44 pri!ileges granted to a group

r S0L0# (read

w :PA#0 (writea &6S0R# (append

d 0L0#0

R R:L0x R0"0R060S

arwdRxt

Gt #R&550R

B 0B0:#0

: :SA50 R0A#0

# #0+P1RAR=ALL PR&C&L050S (for tables

grant option for preceding pri!ilege

M**** 44 user who granted this pri!ilege

#he abo!e example displa* would be seen b* user miriam after creating table m*table and doing

0RAT SELECT ! m5table T! P,-LC$0RAT SELECT2 ,PDATE2 SERT ! m5table T! 0R!,P todos$

&f the $Access pri!ileges% column is empt* for a gi!en object, it means the object has defaultpri!ileges (that is, its pri!ileges column is null. efault pri!ileges alwa*s include all pri!ileges for

the owner, and ma* include some pri!ileges for P:>L& depending on the object t*pe, as explainedabo!e.

#he first 5RA6# or R0C1D0 on an object will instantiate the default pri!ileges (producing, forexample,

OmiriamHarwdRxtMmiriam and then modif* them per the specified re/uest.

6otice that the owner8s implicit grant options are not mar)ed in the access pri!ileges displa*. A Gwill appear onl* when grant options ha!e been explicitl* granted to someone.


20/26

E(amples

5rant insert pri!ilege to all users on table films2

0RAT SERT ! 'ilms T! P,-LC$

5rant all a!ailable pri!ileges to user manuel on !iew )inds2

0RAT ALL PR3LE0ES ! Kinds T! man&el$

6ote that while the abo!e will indeed grant all pri!ileges if executed b* a superuser or the owner of

)inds, when executed b* someone else it will onl* grant those permissions for which the someoneelse has grant options.

5rant membership in role admins to user joe2

0RAT admins T! oe$

ompatibilit* According to the SQL standard, the PR&C&L050S )e* word in ALL PR&C&L050S is

re/uired. #he SQL standard does not support setting the pri!ileges on more than one object percommand.

PostgreSQL allows an object owner to re!o)e his own ordinar* pri!ileges2 for example, a table

owner can ma)e the table read4onl* to himself b* re!o)ing his own &6S0R#, :PA#0, and

0L0#0 pri!ileges.

#his is not possible according to the SQL standard. #he reason is that PostgreSQL treats theowner8s pri!ileges as ha!ing been granted b* the owner to himself3 therefore he can re!o)e them

too. &n the SQL standard, the owner8s pri!ileges are granted b* an assumed entit* $7S=S#0+%. 6ot

being $7S=S#0+%, the owner cannot re!o)e these rights.

#he SQL standard allows setting pri!ileges for indi!idual columns within a table2

5RA6# pri!ileges

16 table I ( column I, ...J J I, ...J#1 O P:>L& K username I, ...J I @? 5RA6# 1P#&16 J

#he SQL standard pro!ides for a :SA50 pri!ilege on other )inds of objects2 character sets,

collations, translations, domains.

#he R:L0 pri!ilege, and pri!ileges on databases, tablespaces, schemas, languages, and se/uences

are PostgreSQL extensions.See Also

R0C1D0


21/26

RE3!4E6ame

R0C1D0 E remo!e access pri!ilegesS*nopsis

RE3!4E = 0RAT !PT! !R >F F SELECT ? SERT ? ,PDATE ? DELETE ? R,LE ? REERECES ? TR00ER G=2...> ? ALL = PR3LE0ES > G! = TA-LE > tablename =2 ...>R!" F &sername ? 0R!,P gro&pname ? P,-LC G =2 ...>= CASCADE ? RESTRCT >

RE3!4E = 0RAT !PT! !R >F F CREATE ? TE"P!RAR@ ? TE"P G =2...> ? ALL = PR3LE0ES > G! DATA-ASE dbname =2 ...>

R!" F &sername ? 0R!,P gro&pname ? P,-LC G =2 ...>= CASCADE ? RESTRCT >

R0C1D0 I 5RA6# 1P#&16 "1R JO 0B0:#0 K ALL I PR&C&L050S J

16 ":6#&16 funcname ( I I argmode J I argname J argt*pe I, ...J J I, ...J

"R1+ O username K 5R1:P groupname K P:>L& I, ...JI ASA0 K R0S#R J

R0C1D0 I 5RA6# 1P#&16 "1R JO :SA50 K ALL I PR&C&L050S J

16 LA65:A50 langname I, ...J


R0C1D0 I 5RA6# 1P#&16 "1R JO O R0A#0 K :SA50 I,...J K ALL I PR&C&L050S J

16 S?0+A schemaname I, ...J


R0C1D0 I 5RA6# 1P#&16 "1R JO R0A#0 K ALL I PR&C&L050S J

16 #A>L0SPA0 tablespacename I, ...J

"R1+ O username K 5R1:P groupname K P:>L& I, ...J

I ASA0 K R0S#R J

RE3!4E = AD" !PT! !R >role =2 ...> R!" &sername =2 ...>= CASCADE ? RESTRCT >

escription

#he R0C1D0 command re!o)es pre!iousl* granted pri!ileges from one or more roles. #he )e*

word P:>L& refers to the implicitl* defined group of all roles.

See the description of the 5RA6# command for the meaning of the pri!ilege t*pes.6ote that an* particular role will ha!e the sum of pri!ileges granted directl* to it, pri!ileges grantedto an* role it is presentl* a member of, and pri!ileges granted to P:>L&. #hus, for example,


22/26

re!o)ing S0L0# pri!ilege from P:>L& does not necessaril* mean that all roles ha!e lost

S0L0# pri!ilege on the object2

those who ha!e it granted directl* or !ia another role will still ha!e it.

&f 5RA6# 1P#&16 "1R is specified, onl* the grant option for the pri!ilege is re!o)ed, not the

pri!ilege itself. 1therwise, both the pri!ilege and the grant option are re!o)ed.

&f a user holds a pri!ilege with grant option and has granted it to other users then the pri!ileges held

b* those other users are called dependent pri!ileges. &f the pri!ilege or the grant option held b* thefirst user is being re!o)ed and dependent pri!ileges exist, those dependent pri!ileges are also

re!o)ed if ASA0 is specified, else the re!o)e action will fail. #his recursi!e re!ocation onl*affects pri!ileges that were granted through a chain of users that is traceable to the user that is the

subject of this R0C1D0 command.

#hus, the affected users ma* effecti!el* )eep the pri!ilege if it was also granted through other

users.

@hen re!o)ing membership in a role, 5RA6# 1P#&16 is instead called A+&6 1P#&16, but the

beha!ior is similar. 6ote also that this form of the command does not allow the noise word 5R1:P.6otes

:sepsql:s %H commandto displa* the pri!ileges granted on existing objects. See 5RA6# forinformation about the format.

A user can onl* re!o)e pri!ileges that were granted directl* b* that user. &f, for example, user A has

granted a pri!ilege with grant option to user >, and user > has in turned granted it to user , thenuser A cannot re!o)e the pri!ilege directl* from . &nstead, user A could re!o)e the grant option

from user > and use the ASA0 option so that the pri!ilege is in turn re!o)ed from user . "or

another example, if both

A and > ha!e granted the same pri!ilege to , A can re!o)e his own grant but not >8s grant, so will still effecti!el* ha!e the pri!ilege.

@hen a non4owner of an object attempts to R0C1D0 pri!ileges on the object, the command willfail outright if the user has no pri!ileges whatsoe!er on the object. As long as some pri!ilege is

a!ailable, the command will proceed, but it will re!o)e onl* those pri!ileges for which the user hasgrant options.

#he R0C1D0 ALL PR&C&L050S forms will issue a warning message if no grant options are held,while the other forms will issue a warning if grant options for an* of the pri!ileges specificall*

named in the command are not held. (&n principle these statements appl* to the object owner aswell, but since the owner is alwa*s treated as holding all grant options, the cases can ne!er occur.

&f a superuser chooses to issue a 5RA6# or R0C1D0 command, the command is performed asthough it were issued b* the owner of the affected object. Since all pri!ileges ultimatel* come from

the object owner (possibl* indirectl* !ia chains of grant options, it is possible for a superuser tore!o)e all pri!ileges, but this ma* re/uire use of ASA0 as stated abo!e.

R0C1D0 can also be done b* a role that is not the owner of the affected object, but is a member ofthe role that owns the object, or is a member of a role that holds pri!ileges @? 5RA6# 1P#&16

on the object.


23/26

&n this case the command is performed as though it were issued b* the containing role that actuall*

owns the object or holds the pri!ileges @? 5RA6# 1P#&16. "or example, if table t is ownedb* role g, of which role u is a member, then u can re!o)e pri!ileges on t that are recorded as

being granted b* g.

#his would include grants made b* u as well as b* other members of role g.

&f the role executing R0C1D0 holds pri!ileges indirectl* !ia more than one role membership path,

it is unspecified which containing role will be used to perform the command. &n such cases it is best

practice to use S0# R1L0 to become the specific role *ou want to do the R0C1D0 as. "ailure todo so ma* lead to re!o)ing pri!ileges other than the ones *ou intended, or not re!o)ing an*thing at

all.

E(amples

Re!o)e insert pri!ilege for the public on table films2

RE3!4E SERT ! 'ilms R!" P,-LC$

Re!o)e all pri!ileges from user manuel on !iew )inds2

RE3!4E ALL PR3LE0ES ! Kinds R!" man&el$

6ote that this actuall* means $re!o)e all pri!ileges that & granted%.

Re!o)e membership in role admins from user joe2

RE3!4E admins R!" oe$

ompatibilit*#he compatibilit* notes of the 5RA6# command appl* analogousl* to R0C1D0. #he s*ntax

summar* is2R0C1D0 I 5RA6# 1P#&16 "1R J pri!ileges

16 object I ( column I, ...J J

"R1+ O P:>L& K username I, ...J O R0S#R K ASA0

1ne of R0S#R or ASA0 is re/uired according to the standard, but PostgreSQL assumes

R0S#R b* default.See Also


24/26

ALTER ROLE

Name

AL#0R R1L0 44 change a database role

SynopsisALTER ROLE name [ [ WITH ] option [ ... ] ]

where option can be:

SUPERUSER | OSUPERUSER | !REATE"# | O!REATE"# | !REATEROLE | O!REATEROLE | !REATEUSER | O!REATEUSER

| IHERIT | OIHERIT | LO$I | OLO$I | REPLI!ATIO | OREPLI!ATIO | !OE!TIO LI%IT conn&imit | [ E!R'PTE" | UE!R'PTE" ] PASSWOR" (pa))wor*( | +ALI" UTIL (time)tamp(

ALTER ROLE name REA%E TO new,name

ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] SET con-i/ration,parameter 0 TO |1 2 0 3a&/e | "E4AULT 2ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] SET con-i/ration,parameter 4RO%!URRETALTER ROLE name [ I "ATA#ASE *ataba)e,name ] RESET con-i/ration,parameterALTER ROLE name [ I "ATA#ASE *ataba)e,name ] RESET ALL

Description

ALTER ROLEchanges the attributes of a PostgreSQL role.

#he first !ariant of this command listed in the s*nopsis can change man* of the role attributes that

can be specified in R0A#0 R1L0. (All the possible attributes are co!ered, except that there are no

options for adding or remo!ing memberships3 use 5RA6#and R0C1D0for that. Attributes not

mentioned in the command retain their pre!ious settings. atabase superusers can change an* ofthese settings for an* role. Roles ha!ing !REATEROLEpri!ilege can change an* of these settings,but onl* for non4superuser and non4replication roles. 1rdinar* roles can onl* change their own

password.

#he second !ariant changes the name of the role. atabase superusers can rename an* role. Rolesha!ing !REATEROLEpri!ilege can rename non4superuser roles. #he current session user cannot berenamed. (onnect as a different user if *ou need to do that. >ecause %"54encr*pted passwordsuse the role name as cr*ptographic salt, renaming a role clears its password if the password is %"54encr*pted.

#he remaining !ariants change a roleTs session default for a configuration !ariable, either for all

databases or, when the I "ATA#ASEclause is specified, onl* for sessions in the named database.@hene!er the role subse/uentl* starts a new session, the specified !alue becomes the session

default, o!erriding whate!er setting is present in po)tre)6&.con-or has been recei!ed from
http://www.postgresql.org/docs/9.1/static/sql-createrole.htmlhttp://www.postgresql.org/docs/9.1/static/sql-grant.htmlhttp://www.postgresql.org/docs/9.1/static/sql-revoke.htmlhttp://www.postgresql.org/docs/9.1/static/sql-grant.htmlhttp://www.postgresql.org/docs/9.1/static/sql-revoke.htmlhttp://www.postgresql.org/docs/9.1/static/sql-createrole.html


25/26

the po)tre)command line. #his onl* happens at login time3 executing S0# R1L0or S0#S0SS&16 A:#?1R&UA#&16does not cause new configuration !alues to be set. Settings set for all

databases are o!erridden b* database4specific settings attached to a role. Superusers can changean*oneTs session defaults. Roles ha!ing !REATEROLEpri!ilege can change defaults for non4superuser roles. 1rdinar* roles can onl* set defaults for themsel!es. ertain configuration !ariables

cannot be set this wa*, or can onl* be set if a superuser issues the command.

Parameters

name

#he name of the role whose attributes are to be altered.

SUPERUSEROSUPERUSER!REATE"#O!REATE"#!REATEROLEO!REATEROLE!REATEUSERO!REATEUSERIHERITOIHERITLO$IOLO$IREPLI!ATIOOREPLI!ATIO

!OE!TIO LI%ITconn&imitPASSWOR"pa))wor*E!R'PTE"UE!R'PTE"+ALI" UTILTtime)tampT

#hese clauses alter attributes originall* set b* R0A#0 R1L0. "or more information, see the

!REATE ROLEreference page.

new,name

#he new name of the role.

*ataba)e,name

#he name of the database the configuration !ariable should be set in.

con-i/ration,parameter3a&/e

Set this roleTs session default for the specified configuration parameter to the gi!en !alue. &f

3a&/eis "E4AULTor, e/ui!alentl*, RESETis used, the role4specific !ariable setting isremo!ed, so the role will inherit the s*stem4wide default setting in new sessions. :se RESETALLto clear all role4specific settings. SET 4RO% !URRETsa!es the sessionTs current
http://www.postgresql.org/docs/9.1/static/sql-set-role.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-role.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-session-authorization.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-session-authorization.htmlhttp://www.postgresql.org/docs/9.1/static/sql-createrole.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-role.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-session-authorization.htmlhttp://www.postgresql.org/docs/9.1/static/sql-set-session-authorization.htmlhttp://www.postgresql.org/docs/9.1/static/sql-createrole.html


26/26

!alue of the parameter as the role4specific !alue. &f I "ATA#ASEis specified, theconfiguration parameter is set or remo!ed for the gi!en role and database onl*.

Role4specific !ariable settings ta)e effect onl* at login3 S0# R1L0and S0# S0SS&16

A:#?1R&UA#&16do not process role4specific !ariable settings.

SeeS0#and hapter 'for more information about allowed parameter names and !alues.

Notes

:se R0A#0 R1L0to add new roles, and R1P R1L0to remo!e a role.

ALTER ROLEcannot change a roleTs memberships. :se 5RA6#and R0C1D0to do that.

aution must be exercised when specif*ing an unencr*pted password with this command. #hepassword will be transmitted to the ser!er in cleartext, and it might also be logged in the clientTs

command histor* or the ser!er log. ps/lcontains a command 7pa))wor*that can be used to

change a roleTs password without exposing the cleartext password.

&t is also possible to tie a session default to a specific database rather than to a role3 see AL#0R

A#A>AS0. &f there is a conflict, database4role4specific settings o!erride role4specific ones, whichin turn o!erride database4specific ones.

Examples

hange a roleTs password2

ALTER ROLE *a3i*e WITH PASSWOR" (h/89mn(;

Remo!e a roleTs password2

ALTER ROLE *a3i*e WITH PASSWOR" ULL;

hange a password expiration date, specif*ing that the password should expire at midda* on Nth+a* ;

Documents

DCL Postgresql.pdf