Merge two documentation permission chapters into a single chapter.
This commit is contained in:
parent
087bd179e6
commit
48d25bac9f
@ -1400,13 +1400,33 @@ ALTER TABLE products RENAME TO items;
|
|||||||
<see>privilege</see>
|
<see>privilege</see>
|
||||||
</indexterm>
|
</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>
|
<para>
|
||||||
When you create a database object, you become its owner. By
|
When an object is created, it is assigned an owner. The
|
||||||
default, only the owner of an object can do anything with the
|
owner is normally the role that executed the creation statement.
|
||||||
object. In order to allow other users to use it,
|
For most kinds of objects, the initial state is that only the owner
|
||||||
<firstterm>privileges</firstterm> must be granted. (However,
|
(or a superuser) can do anything with the object. To allow
|
||||||
users that have the superuser attribute can always
|
other roles to use it, <firstterm>privileges</firstterm> must be
|
||||||
access any object.)
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -1429,14 +1449,14 @@ ALTER TABLE products RENAME TO items;
|
|||||||
the owner only.
|
the owner only.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<para>
|
||||||
<para>
|
An object can be assigned to a new owner with an <command>ALTER</command>
|
||||||
To change the owner of a table, index, sequence, or view, use the
|
command of the appropriate kind for the object, e.g. <xref
|
||||||
<xref linkend="sql-altertable">
|
linkend="sql-altertable">. Superusers can always do
|
||||||
command. There are corresponding <literal>ALTER</> commands for
|
this; ordinary roles can only do it if they are both the current owner
|
||||||
other object types.
|
of the object (or a member of the owning role) and a member of the new
|
||||||
</para>
|
owning role.
|
||||||
</note>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To assign privileges, the <command>GRANT</command> command is
|
To assign privileges, the <command>GRANT</command> command is
|
||||||
|
@ -1,7 +1,7 @@
|
|||||||
<!-- doc/src/sgml/user-manag.sgml -->
|
<!-- doc/src/sgml/user-manag.sgml -->
|
||||||
|
|
||||||
<chapter id="user-manag">
|
<chapter id="user-manag">
|
||||||
<title>Database Roles and Privileges</title>
|
<title>Database Roles</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname> manages database access permissions
|
<productname>PostgreSQL</productname> manages database access permissions
|
||||||
@ -22,10 +22,9 @@
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This chapter describes how to create and manage roles and introduces
|
This chapter describes how to create and manage roles.
|
||||||
the privilege system. More information about the various types of
|
More information about the effects of privileges on various database
|
||||||
database objects and the effects of privileges can be found in
|
objects can be found in <xref linkend="ddl-priv">.
|
||||||
<xref linkend="ddl">.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1 id="database-roles">
|
<sect1 id="database-roles">
|
||||||
@ -282,81 +281,6 @@ ALTER ROLE myname SET enable_indexscan TO off;
|
|||||||
</para>
|
</para>
|
||||||
</sect1>
|
</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">
|
<sect1 id="role-membership">
|
||||||
<title>Role Membership</title>
|
<title>Role Membership</title>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user