diff options
Diffstat (limited to 'doc/src/sgml/user-manag.sgml')
| -rw-r--r-- | doc/src/sgml/user-manag.sgml | 170 |
1 files changed, 93 insertions, 77 deletions
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml index cadca53ace6..fb8f84a4916 100644 --- a/doc/src/sgml/user-manag.sgml +++ b/doc/src/sgml/user-manag.sgml @@ -1,5 +1,5 @@ <!-- -$PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.32 2005/10/15 20:12:33 neilc Exp $ +$PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.33 2005/10/20 19:18:00 tgl Exp $ --> <chapter id="user-manag"> @@ -267,6 +267,81 @@ ALTER ROLE myname SET enable_indexscan TO off; </para> </sect1> + <sect1 id="privileges"> + <title>Privileges</title> + + <indexterm zone="privileges"> + <primary>privilege</primary> + </indexterm> + + <indexterm zone="privileges"> + <primary>owner</primary> + </indexterm> + + <indexterm zone="privileges"> + <primary>GRANT</primary> + </indexterm> + + <indexterm zone="privileges"> + <primary>REVOKE</primary> + </indexterm> + + <para> + 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, <firstterm>privileges</firstterm> must be + granted. + There are several different kinds of privilege: <literal>SELECT</>, + <literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>, + <literal>RULE</>, <literal>REFERENCES</>, <literal>TRIGGER</>, + <literal>CREATE</>, <literal>TEMPORARY</>, <literal>EXECUTE</>, + and <literal>USAGE</>. For more + information on the different types of privileges supported by + <productname>PostgreSQL</productname>, see the + <xref linkend="sql-grant" endterm="sql-grant-title"> reference page. + </para> + + <para> + To assign privileges, the <command>GRANT</command> command is + used. So, if <literal>joe</literal> is an existing role, and + <literal>accounts</literal> is an existing table, the privilege to + update the table can be granted with +<programlisting> +GRANT UPDATE ON accounts TO joe; +</programlisting> + The special name <literal>PUBLIC</literal> can + be used to grant a privilege to every role on the system. Writing + <literal>ALL</literal> in place of a specific privilege specifies that all + privileges that apply to the object will be granted. + </para> + + <para> + To revoke a privilege, use the fittingly named + <xref linkend="sql-revoke" endterm="sql-revoke-title"> command: +<programlisting> +REVOKE ALL ON accounts FROM PUBLIC; +</programlisting> + </para> + + <para> + 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. + </para> + + <para> + An object can be assigned to a new owner with an <command>ALTER</command> + 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. + </para> + </sect1> + <sect1 id="role-membership"> <title>Role Membership</title> @@ -374,6 +449,22 @@ RESET ROLE; </note> <para> + The role attributes <literal>LOGIN</>, <literal>SUPERUSER</>, + <literal>CREATEDB</>, and <literal>CREATEROLE</> can be thought of as + special privileges, but they are never inherited as ordinary privileges + on database objects are. You must actually <command>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 <literal>CREATEDB</> and <literal>CREATEROLE</> to the + <literal>admin</> role. Then a session connecting as role <literal>joe</> + would not have these privileges immediately, only after doing + <command>SET ROLE admin</>. + </para> + + <para> + </para> + + <para> To destroy a group role, use <xref linkend="sql-droprole" endterm="sql-droprole-title">: <synopsis> @@ -386,87 +477,12 @@ DROP ROLE <replaceable>name</replaceable>; </para> </sect1> - <sect1 id="privileges"> - <title>Privileges</title> - - <indexterm zone="privileges"> - <primary>privilege</primary> - </indexterm> - - <indexterm zone="privileges"> - <primary>owner</primary> - </indexterm> - - <indexterm zone="privileges"> - <primary>GRANT</primary> - </indexterm> - - <indexterm zone="privileges"> - <primary>REVOKE</primary> - </indexterm> - - <para> - 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, <firstterm>privileges</firstterm> must be - granted. - There are several different kinds of privilege: <literal>SELECT</>, - <literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>, - <literal>RULE</>, <literal>REFERENCES</>, <literal>TRIGGER</>, - <literal>CREATE</>, <literal>TEMPORARY</>, <literal>EXECUTE</>, - and <literal>USAGE</>. For more - information on the different types of privileges supported by - <productname>PostgreSQL</productname>, see the - <xref linkend="sql-grant" endterm="sql-grant-title"> reference page. - </para> - - <para> - To assign privileges, the <command>GRANT</command> command is - used. So, if <literal>joe</literal> is an existing role, and - <literal>accounts</literal> is an existing table, the privilege to - update the table can be granted with -<programlisting> -GRANT UPDATE ON accounts TO joe; -</programlisting> - The special name <literal>PUBLIC</literal> can - be used to grant a privilege to every role on the system. Writing - <literal>ALL</literal> in place of a specific privilege specifies that all - privileges that apply to the object will be granted. - </para> - - <para> - To revoke a privilege, use the fittingly named - <xref linkend="sql-revoke" endterm="sql-revoke-title"> command: -<programlisting> -REVOKE ALL ON accounts FROM PUBLIC; -</programlisting> - </para> - - <para> - 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. - </para> - - <para> - An object can be assigned to a new owner with an <command>ALTER</command> - 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. - </para> - </sect1> - <sect1 id="perm-functions"> <title>Functions and Triggers</title> <para> 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 <quote>Trojan horse</quote> others with relative ease. The only real protection is tight control over who can define functions. |