mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-12 15:39:35 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge two documentation permission chapters into a single chapter.

Browse Source
This commit is contained in:
Bruce Momjian 2011-02-20 22:20:57 -05:00
parent 087bd179e6
commit 48d25bac9f
2 changed files with 38 additions and 94 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/src/sgml/ddl.sgml
View File

@ -1400,13 +1400,33 @@ ALTER TABLE products RENAME TO items;
<see>privilege</see>
</indexterm>
<indexterm zone="ddl-priv">
<primary>owner</primary>
</indexterm>
<indexterm zone="ddl-priv">
<primary>GRANT</primary>
</indexterm>
<indexterm zone="ddl-priv">
<primary>REVOKE</primary>
</indexterm>
<para>
When you create a database object, you become its owner. By
default, only the owner of an object can do anything with the
object. In order to allow other users to use it,
<firstterm>privileges</firstterm> must be granted. (However,
users that have the superuser attribute can always
access any object.)
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>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
<literal>CREATE</>, <literal>CONNECT</>, <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"> reference page.
</para>
<para>
@ -1429,14 +1449,14 @@ ALTER TABLE products RENAME TO items;
the owner only.
</para>
<note>
<para>
To change the owner of a table, index, sequence, or view, use the
<xref linkend="sql-altertable">
command. There are corresponding <literal>ALTER</> commands for
other object types.
</para>
</note>
<para>
An object can be assigned to a new owner with an <command>ALTER</command>
command of the appropriate kind for the object, e.g. <xref
linkend="sql-altertable">. 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>
<para>
To assign privileges, the <command>GRANT</command> command is

84
doc/src/sgml/user-manag.sgml
View File

@ -1,7 +1,7 @@
<!-- doc/src/sgml/user-manag.sgml -->
<chapter id="user-manag">
<title>Database Roles and Privileges</title>
<title>Database Roles</title>
<para>
<productname>PostgreSQL</productname> manages database access permissions
@ -22,10 +22,9 @@
</para>
<para>
This chapter describes how to create and manage roles and introduces
the privilege system. More information about the various types of
database objects and the effects of privileges can be found in
<xref linkend="ddl">.
This chapter describes how to create and manage roles.
More information about the effects of privileges on various database
objects can be found in <xref linkend="ddl-priv">.
</para>
<sect1 id="database-roles">
@ -282,81 +281,6 @@ 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>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
<literal>CREATE</>, <literal>CONNECT</>, <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"> 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"> 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>