diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml index 8e8196f480d230046db3329ba6c480a029e64b2e..bb9571abd8363a5622abeaa51ee35af9fe898176 100644 --- a/doc/src/sgml/ref/grant.sgml +++ b/doc/src/sgml/ref/grant.sgml @@ -1,5 +1,5 @@ @@ -343,6 +343,29 @@ GRANT role [, ...] by the containing role itself.) + + GRANT and REVOKE can also be done by 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 privileges + WITH GRANT OPTION on the object. In this case the + privileges will be recorded as having been granted by the role that + actually owns the object or holds the privileges + WITH GRANT OPTION. For example, if table + t1 is owned by role g1, of which role + u1 is a member, then u1 can grant privileges + on t1 to u2, but those privileges will appear + to have been granted directly by g1. Any other member + of role g1 could revoke them later. + + + + If the role executing GRANT holds the required privileges + indirectly via more than one role membership path, it is unspecified + which containing role will be recorded as having done the grant. In such + cases it is best practice to use SET ROLE to become the + specific role you want to do the GRANT as. + + Currently, PostgreSQL does not support granting or revoking privileges for individual columns of a table. diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml index 58219c55cefc1cf1bb6d2ab2f1a3e6bf0779db86..68c69f8814fe87ced871056157d705b22cecee15 100644 --- a/doc/src/sgml/ref/revoke.sgml +++ b/doc/src/sgml/ref/revoke.sgml @@ -1,5 +1,5 @@ @@ -158,6 +158,31 @@ REVOKE [ ADMIN OPTION FOR ] it is possible for a superuser to revoke all privileges, but this may require use of CASCADE as stated above. + + + REVOKE can also be done by 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 privileges + WITH GRANT OPTION on the object. In this case the + command is performed as though it were issued by the containing role that + actually owns the object or holds the privileges + WITH GRANT OPTION. For example, if table + t1 is owned by role g1, of which role + u1 is a member, then u1 can revoke privileges + on t1 that are recorded as being granted by g1. + This would include grants made by u1 as well as by other + members of role g1. + + + + If the role executing REVOKE holds privileges + indirectly via more than one role membership path, it is unspecified + which containing role will be used to perform the command. In such cases + it is best practice to use SET ROLE to become the specific + role you want to do the REVOKE as. Failure to do so may + lead to revoking privileges other than the ones you intended, or not + revoking anything at all. + diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml index cadca53ace6aa3d41cc5939260492b4708dfe62a..fb8f84a4916029ea4ecefcb89dffc2e151d92af4 100644 --- a/doc/src/sgml/user-manag.sgml +++ b/doc/src/sgml/user-manag.sgml @@ -1,5 +1,5 @@ @@ -267,6 +267,81 @@ ALTER ROLE myname SET enable_indexscan TO off; + + Privileges + + + privilege + + + + owner + + + + GRANT + + + + REVOKE + + + + When an object is created, it is assigned an owner. The + owner is normally the role that executed the creation statement. + For most kinds of objects, the initial state is that only the owner + (or a superuser) can do anything with the object. To allow + other roles to use it, privileges must be + granted. + There are several different kinds of privilege: SELECT, + INSERT, UPDATE, DELETE, + RULE, REFERENCES, TRIGGER, + CREATE, TEMPORARY, EXECUTE, + and USAGE. For more + information on the different types of privileges supported by + PostgreSQL, see the + reference page. + + + + To assign privileges, the GRANT command is + used. So, if joe is an existing role, and + accounts is an existing table, the privilege to + update the table can be granted with + +GRANT UPDATE ON accounts TO joe; + + The special name PUBLIC can + be used to grant a privilege to every role on the system. Writing + ALL in place of a specific privilege specifies that all + privileges that apply to the object will be granted. + + + + To revoke a privilege, use the fittingly named + command: + +REVOKE ALL ON accounts FROM PUBLIC; + + + + + The special privileges of an object's owner (i.e., the right to modify + or destroy the object) are always implicit in being the owner, + and cannot be granted or revoked. But the owner can choose + to revoke his own ordinary privileges, for example to make a + table read-only for himself as well as others. + + + + An object can be assigned to a new owner with an ALTER + command of the appropriate kind for the object. Superusers can always do + this; ordinary roles can only do it if they are both the current owner + of the object (or a member of the owning role) and a member of the new + owning role. + + + Role Membership @@ -373,6 +448,22 @@ RESET ROLE; + + The role attributes LOGIN, SUPERUSER, + CREATEDB, and CREATEROLE can be thought of as + special privileges, but they are never inherited as ordinary privileges + on database objects are. You must actually SET ROLE to a + specific role having one of these attributes in order to make use of + the attribute. Continuing the above example, we might well choose to + grant CREATEDB and CREATEROLE to the + admin role. Then a session connecting as role joe + would not have these privileges immediately, only after doing + SET ROLE admin. + + + + + To destroy a group role, use : @@ -386,87 +477,12 @@ DROP ROLE name; - - Privileges - - - privilege - - - - owner - - - - GRANT - - - - REVOKE - - - - When an object is created, it is assigned an owner. The - owner is normally the role that executed the creation statement. - For most kinds of objects, the initial state is that only the owner - (or a superuser) can do anything with the object. To allow - other roles to use it, privileges must be - granted. - There are several different kinds of privilege: SELECT, - INSERT, UPDATE, DELETE, - RULE, REFERENCES, TRIGGER, - CREATE, TEMPORARY, EXECUTE, - and USAGE. For more - information on the different types of privileges supported by - PostgreSQL, see the - reference page. - - - - To assign privileges, the GRANT command is - used. So, if joe is an existing role, and - accounts is an existing table, the privilege to - update the table can be granted with - -GRANT UPDATE ON accounts TO joe; - - The special name PUBLIC can - be used to grant a privilege to every role on the system. Writing - ALL in place of a specific privilege specifies that all - privileges that apply to the object will be granted. - - - - To revoke a privilege, use the fittingly named - command: - -REVOKE ALL ON accounts FROM PUBLIC; - - - - - The special privileges of an object's owner (i.e., the right to modify - or destroy the object) are always implicit in being the owner, - and cannot be granted or revoked. But the owner can choose - to revoke his own ordinary privileges, for example to make a - table read-only for himself as well as others. - - - - An object can be assigned to a new owner with an ALTER - command of the appropriate kind for the object. Superusers can always do - this; ordinary roles can only do it if they are both the current owner - of the object (or a member of the owning role) and a member of the new - owning role. - - - Functions and Triggers Functions and triggers allow users to insert code into the backend - server that other users may execute without knowing it. Hence, both + server that other users may execute unintentionally. Hence, both mechanisms permit users to Trojan horse others with relative ease. The only real protection is tight control over who can define functions.