2002-08-16 06:47:43 +02:00
|
|
|
<!--
|
2005-03-25 17:38:58 +01:00
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.29 2005/03/25 16:38:58 tgl Exp $
|
2002-08-16 06:47:43 +02:00
|
|
|
-->
|
|
|
|
|
|
|
|
<chapter id="user-manag">
|
2002-09-25 23:16:10 +02:00
|
|
|
<title>Database Users and Privileges</title>
|
2000-06-18 23:24:54 +02:00
|
|
|
|
|
|
|
<para>
|
2002-09-25 23:16:10 +02:00
|
|
|
Every database cluster contains a set of database users. Those
|
|
|
|
users are separate from the users managed by the operating system on
|
|
|
|
which the server runs. Users own database objects (for example,
|
|
|
|
tables) and can assign privileges on those objects to other users to
|
|
|
|
control who has access to which object.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This chapter describes how to create and manage users and introduces
|
|
|
|
the privilege system. More information about the various types of
|
2003-03-25 17:15:44 +01:00
|
|
|
database objects and the effects of privileges can be found in <xref linkend="ddl">.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="database-users">
|
2000-06-18 23:24:54 +02:00
|
|
|
<title>Database Users</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="database-users">
|
|
|
|
<primary>user</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm>
|
|
|
|
<primary>CREATE USER</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm>
|
|
|
|
<primary>DROP USER</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<para>
|
2001-11-17 23:23:55 +01:00
|
|
|
Database users are conceptually completely separate from
|
2000-06-18 23:24:54 +02:00
|
|
|
operating system users. In practice it might be convenient to
|
|
|
|
maintain a correspondence, but this is not required. Database user
|
|
|
|
names are global across a database cluster installation (and not
|
2005-01-08 23:13:38 +01:00
|
|
|
per individual database). To create a user use the <xref
|
|
|
|
linkend="sql-createuser" endterm="sql-createuser-title"> SQL command:
|
2000-06-18 23:24:54 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
CREATE USER <replaceable>name</replaceable>;
|
2000-06-18 23:24:54 +02:00
|
|
|
</synopsis>
|
|
|
|
<replaceable>name</replaceable> follows the rules for SQL
|
|
|
|
identifiers: either unadorned without special characters, or
|
2001-11-28 21:49:10 +01:00
|
|
|
double-quoted. To remove an existing user, use the analogous
|
2005-01-08 23:13:38 +01:00
|
|
|
<xref linkend="sql-dropuser" endterm="sql-dropuser-title"> command:
|
2002-09-25 23:16:10 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
DROP USER <replaceable>name</replaceable>;
|
2002-09-25 23:16:10 +02:00
|
|
|
</synopsis>
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>createuser</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<indexterm>
|
|
|
|
<primary>dropuser</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<para>
|
2005-01-08 23:13:38 +01:00
|
|
|
For convenience, the programs <xref linkend="app-createuser">
|
|
|
|
and <xref linkend="app-dropuser"> are provided as wrappers
|
2002-09-25 23:16:10 +02:00
|
|
|
around these SQL commands that can be called from the shell command
|
|
|
|
line:
|
|
|
|
<synopsis>
|
|
|
|
createuser <replaceable>name</replaceable>
|
|
|
|
dropuser <replaceable>name</replaceable>
|
|
|
|
</synopsis>
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
2005-01-08 23:13:38 +01:00
|
|
|
<para>
|
|
|
|
To determine the set of existing users, examine the <structname>pg_user</>
|
|
|
|
system catalog, for example
|
|
|
|
<synopsis>
|
|
|
|
SELECT usename FROM pg_user;
|
|
|
|
</synopsis>
|
|
|
|
The <xref linkend="app-psql"> program's <literal>\du</> meta-command
|
|
|
|
is also useful for listing the existing users.
|
|
|
|
</para>
|
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<para>
|
|
|
|
In order to bootstrap the database system, a freshly initialized
|
2001-09-08 17:24:00 +02:00
|
|
|
system always contains one predefined user. This user will have the
|
2002-09-25 23:16:10 +02:00
|
|
|
fixed ID 1, and by default (unless altered when running
|
2003-03-13 02:30:29 +01:00
|
|
|
<command>initdb</command>) it will have the same name as the
|
|
|
|
operating system user that initialized the database
|
2002-08-16 06:47:43 +02:00
|
|
|
cluster. Customarily, this user will be named
|
2003-03-13 02:30:29 +01:00
|
|
|
<literal>postgres</literal>. In order to create more users you
|
|
|
|
first have to connect as this initial user.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2002-09-25 23:16:10 +02:00
|
|
|
Exactly one user identity is active for a connection to the
|
|
|
|
database server. The user name to use for a particular database
|
|
|
|
connection is indicated by the client that is initiating the
|
|
|
|
connection request in an application-specific fashion. For example,
|
2003-03-13 02:30:29 +01:00
|
|
|
the <command>psql</command> program uses the
|
2002-09-25 23:16:10 +02:00
|
|
|
<option>-U</option> command line option to indicate the user to
|
|
|
|
connect as. Many applications assume the name of the current
|
|
|
|
operating system user by default (including
|
2003-03-13 02:30:29 +01:00
|
|
|
<command>createuser</> and <command>psql</>). Therefore it
|
2002-09-25 23:16:10 +02:00
|
|
|
is convenient to maintain a naming correspondence between the two
|
|
|
|
user sets.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The set of database users a given client connection may connect as
|
|
|
|
is determined by the client authentication setup, as explained in
|
2000-06-18 23:24:54 +02:00
|
|
|
<xref linkend="client-authentication">. (Thus, a client is not
|
|
|
|
necessarily limited to connect as the user with the same name as
|
2005-01-08 23:13:38 +01:00
|
|
|
its operating system user, just as a person's login name
|
|
|
|
need not match her real name.) Since the user
|
2002-09-25 23:16:10 +02:00
|
|
|
identity determines the set of privileges available to a connected
|
|
|
|
client, it is important to carefully configure this when setting up
|
|
|
|
a multiuser environment.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
2002-09-25 23:16:10 +02:00
|
|
|
</sect1>
|
2000-06-18 23:24:54 +02:00
|
|
|
|
2002-09-25 23:16:10 +02:00
|
|
|
<sect1 id="user-attributes">
|
|
|
|
<title>User Attributes</title>
|
2000-06-18 23:24:54 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
A database user may have a number of attributes that define its
|
|
|
|
privileges and interact with the client authentication system.
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2003-08-31 19:32:24 +02:00
|
|
|
<term>superuser<indexterm><primary>superuser</></></term>
|
2000-06-18 23:24:54 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A database superuser bypasses all permission checks. Also,
|
|
|
|
only a superuser can create new users. To create a database
|
2002-08-16 06:47:43 +02:00
|
|
|
superuser, use <literal>CREATE USER <replaceable>name</replaceable>
|
2000-06-18 23:24:54 +02:00
|
|
|
CREATEUSER</literal>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2003-08-31 19:32:24 +02:00
|
|
|
<term>database creation<indexterm><primary>database</><secondary>privilege to create</></></term>
|
2000-06-18 23:24:54 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A user must be explicitly given permission to create databases
|
|
|
|
(except for superusers, since those bypass all permission
|
2002-08-16 06:47:43 +02:00
|
|
|
checks). To create such a user, use <literal>CREATE USER
|
|
|
|
<replaceable>name</replaceable> CREATEDB</literal>.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2003-08-31 19:32:24 +02:00
|
|
|
<term>password<indexterm><primary>password</></></term>
|
2000-06-18 23:24:54 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2002-08-16 06:47:43 +02:00
|
|
|
A password is only significant if the client authentication
|
|
|
|
method requires the user to supply a password when connecting
|
2002-11-11 21:14:04 +01:00
|
|
|
to the database. The <option>password</>,
|
2002-08-16 06:47:43 +02:00
|
|
|
<option>md5</>, and <option>crypt</> authentication methods
|
|
|
|
make use of passwords. Database passwords are separate from
|
|
|
|
operating system passwords. Specify a password upon user
|
|
|
|
creation with <literal>CREATE USER
|
2003-03-13 02:30:29 +01:00
|
|
|
<replaceable>name</replaceable> PASSWORD '<replaceable>string</>'</literal>.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
|
2001-11-17 23:23:55 +01:00
|
|
|
A user's attributes can be modified after creation with
|
2003-08-31 19:32:24 +02:00
|
|
|
<command>ALTER USER</command>.<indexterm><primary>ALTER USER</></>
|
2004-02-17 10:07:16 +01:00
|
|
|
See the reference pages for the <xref linkend="sql-createuser"
|
|
|
|
endterm="sql-createuser-title"> and <xref linkend="sql-alteruser"
|
|
|
|
endterm="sql-alteruser-title"> commands for details.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
2002-09-25 23:16:10 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
A user can also set personal defaults for many of the run-time
|
|
|
|
configuration settings described in <xref
|
|
|
|
linkend="runtime-config">. For example, if for some reason you
|
|
|
|
want to disable index scans (hint: not a good idea) anytime you
|
|
|
|
connect, you can use
|
|
|
|
<programlisting>
|
|
|
|
ALTER USER myname SET enable_indexscan TO off;
|
|
|
|
</programlisting>
|
2004-12-27 23:30:10 +01:00
|
|
|
This will save the setting (but not set it immediately). In
|
|
|
|
subsequent connections by this user it will appear as though
|
|
|
|
<literal>SET enable_indexscan TO off;</literal> had been executed
|
|
|
|
just before the session started.
|
2002-09-25 23:16:10 +02:00
|
|
|
You can still alter this setting during the session; it will only
|
|
|
|
be the default. To undo any such setting, use <literal>ALTER USER
|
|
|
|
<replaceable>username</> RESET <replaceable>varname</>;</literal>.
|
|
|
|
</para>
|
2000-06-18 23:24:54 +02:00
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="groups">
|
2000-06-18 23:24:54 +02:00
|
|
|
<title>Groups</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<indexterm zone="groups">
|
|
|
|
<primary>group</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<para>
|
2001-11-17 23:23:55 +01:00
|
|
|
As in Unix, groups are a way of logically grouping users to ease
|
2002-09-25 23:16:10 +02:00
|
|
|
management of privileges: privileges can be granted to, or revoked
|
2005-01-08 23:13:38 +01:00
|
|
|
from, a group as a whole. To create a group, use the <xref
|
|
|
|
linkend="sql-creategroup" endterm="sql-creategroup-title"> SQL command:
|
2000-06-18 23:24:54 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
CREATE GROUP <replaceable>name</replaceable>;
|
2000-06-18 23:24:54 +02:00
|
|
|
</synopsis>
|
2005-01-08 23:13:38 +01:00
|
|
|
|
|
|
|
To add users to or remove users from an existing group, use <xref
|
|
|
|
linkend="sql-altergroup" endterm="sql-altergroup-title">:
|
2000-06-18 23:24:54 +02:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
ALTER GROUP <replaceable>name</replaceable> ADD USER <replaceable>uname1</replaceable>, ... ;
|
|
|
|
ALTER GROUP <replaceable>name</replaceable> DROP USER <replaceable>uname1</replaceable>, ... ;
|
2000-06-18 23:24:54 +02:00
|
|
|
</synopsis>
|
2005-01-08 23:13:38 +01:00
|
|
|
|
|
|
|
To destroy a group, use <xref
|
|
|
|
linkend="sql-dropgroup" endterm="sql-dropgroup-title">:
|
|
|
|
<synopsis>
|
|
|
|
DROP GROUP <replaceable>name</replaceable>;
|
|
|
|
</synopsis>
|
|
|
|
This only drops the group, not its member users.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To determine the set of existing groups, examine the <structname>pg_group</>
|
|
|
|
system catalog, for example
|
|
|
|
<synopsis>
|
|
|
|
SELECT groname FROM pg_group;
|
|
|
|
</synopsis>
|
|
|
|
The <xref linkend="app-psql"> program's <literal>\dg</> meta-command
|
|
|
|
is also useful for listing the existing groups.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="privileges">
|
2000-06-18 23:24:54 +02:00
|
|
|
<title>Privileges</title>
|
|
|
|
|
2003-08-31 19:32:24 +02:00
|
|
|
<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>
|
|
|
|
|
2003-11-24 20:08:02 +01:00
|
|
|
<remark>Being moved to the DDL chapter. Will eventually disappear here.</remark>
|
2002-09-13 00:05:36 +02:00
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<para>
|
2005-02-25 03:34:56 +01:00
|
|
|
When an object is created, it is assigned an owner. The
|
2005-03-25 17:38:58 +01:00
|
|
|
owner is normally the user 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
|
2002-08-16 06:47:43 +02:00
|
|
|
other users to use it, <firstterm>privileges</firstterm> must be
|
|
|
|
granted.
|
2005-03-25 17:38:58 +01:00
|
|
|
There are several different kinds of privilege: <literal>SELECT</>,
|
2002-08-16 06:47:43 +02:00
|
|
|
<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>,
|
|
|
|
<literal>RULE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
|
|
|
|
<literal>CREATE</>, <literal>TEMPORARY</>, <literal>EXECUTE</>,
|
2005-03-25 17:38:58 +01:00
|
|
|
and <literal>USAGE</>. For more
|
2004-12-27 23:30:10 +01:00
|
|
|
information on the different types of privileges supported by
|
2003-08-10 03:20:34 +02:00
|
|
|
<productname>PostgreSQL</productname>, see the
|
|
|
|
<xref linkend="sql-grant" endterm="sql-grant-title"> reference page.
|
2005-03-25 17:38:58 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To assign privileges, the <command>GRANT</command> command is
|
2002-08-16 06:47:43 +02:00
|
|
|
used. So, if <literal>joe</literal> is an existing user, and
|
|
|
|
<literal>accounts</literal> is an existing table, the privilege to
|
|
|
|
update the table can be granted with
|
2000-06-18 23:24:54 +02:00
|
|
|
<programlisting>
|
|
|
|
GRANT UPDATE ON accounts TO joe;
|
|
|
|
</programlisting>
|
2005-03-25 17:38:58 +01:00
|
|
|
To grant a privilege to a group, use
|
2000-06-18 23:24:54 +02:00
|
|
|
<programlisting>
|
|
|
|
GRANT SELECT ON accounts TO GROUP staff;
|
|
|
|
</programlisting>
|
2005-03-25 17:38:58 +01:00
|
|
|
The special name <literal>PUBLIC</literal> can
|
2001-11-28 16:39:49 +01:00
|
|
|
be used to grant a privilege to every user on the system. Writing
|
2001-11-17 23:23:55 +01:00
|
|
|
<literal>ALL</literal> in place of a specific privilege specifies that all
|
2005-03-25 17:38:58 +01:00
|
|
|
privileges that apply to the object will be granted.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To revoke a privilege, use the fittingly named
|
|
|
|
<command>REVOKE</command> command:
|
|
|
|
<programlisting>
|
|
|
|
REVOKE ALL ON accounts FROM PUBLIC;
|
|
|
|
</programlisting>
|
2005-03-25 17:38:58 +01:00
|
|
|
</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
|
2001-11-28 16:39:49 +01:00
|
|
|
to revoke his own ordinary privileges, for example to make a
|
|
|
|
table read-only for himself as well as others.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
2005-03-25 17:38:58 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
An object can be assigned to a new owner with an <command>ALTER</command>
|
|
|
|
command of the appropriate kind for the object. Only superusers can do
|
|
|
|
this.
|
|
|
|
</para>
|
2000-06-18 23:24:54 +02:00
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="perm-functions">
|
2000-06-18 23:24:54 +02:00
|
|
|
<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
|
2003-03-13 02:30:29 +01:00
|
|
|
mechanisms permit users to <quote>Trojan horse</quote>
|
2004-12-27 23:30:10 +01:00
|
|
|
others with relative ease. The only real protection is tight
|
2002-09-25 23:16:10 +02:00
|
|
|
control over who can define functions.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-12-27 23:30:10 +01:00
|
|
|
Functions run inside the backend
|
|
|
|
server process with the operating system permissions of the
|
|
|
|
database server daemon. If the programmming language
|
|
|
|
used for the function allows unchecked memory accesses, it is
|
|
|
|
possible to change the server's internal data structures.
|
2000-06-18 23:24:54 +02:00
|
|
|
Hence, among many other things, such functions can circumvent any
|
2004-12-27 23:30:10 +01:00
|
|
|
system access controls. Function languages that allow such access
|
|
|
|
are considered <quote>untrusted</>, and
|
|
|
|
<productname>PostgreSQL</productname> allows only superusers to
|
|
|
|
create functions written in those languages.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
2002-08-16 06:47:43 +02:00
|
|
|
</chapter>
|