mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Clean up markup for first useful version.
This commit is contained in:
Thomas G. Lockhart
@ -1,155 +1,295 @@
|
|||||||
<chapter id="security">
|
<chapter id="security">
|
||||||
<Title>Security</Title>
|
<Title>Security</Title>
|
||||||
|
|
||||||
<Para>
|
<Para>
|
||||||
|
Database security is addressed at several levels:
|
||||||
|
|
||||||
<Sect1>
|
<itemizedlist>
|
||||||
<Title>User Authentication</Title>
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Data base file protection. All files stored within the database
|
||||||
|
are protected from reading by any account other than the
|
||||||
|
<productname>Postgres</productname> superuser account.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Connections from a client to the database server are, by
|
||||||
|
default, allowed only via a local Unix socket, not via TCP/IP
|
||||||
|
sockets. The backend must be started with the
|
||||||
|
<literal>-i</literal> option to allow non-local clients to connect.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Client connections can be restricted by IP address and/or user
|
||||||
|
name via the <filename>pg_hba.conf</filename> file in <envar>PG_DATA</envar>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Client connections may be authenticated vi other external packages.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Each user in <productname>Postgres</productname> is assigned a
|
||||||
|
username and (optionally) a password. By default, users do not
|
||||||
|
have write access to databases they did not create.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Users may be assigned to <firstterm>groups</firstterm>, and
|
||||||
|
table access may be restricted based on group privileges.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
<Para>
|
<Sect1>
|
||||||
<firstterm>Authentication</firstterm>
|
<Title>User Authentication</Title>
|
||||||
is the process by which the backend server and
|
|
||||||
<application>postmaster</application>
|
|
||||||
ensure that the user requesting access to data is in fact who he/she
|
|
||||||
claims to be.
|
|
||||||
All users who invoke <Productname>Postgres</Productname> are checked against the
|
|
||||||
contents of the <literal>pg_user</literal> class to ensure that they are
|
|
||||||
authorized to do so. However, verification of the user's actual
|
|
||||||
identity is performed in a variety of ways:
|
|
||||||
|
|
||||||
<variablelist>
|
<Para>
|
||||||
<varlistentry>
|
<firstterm>Authentication</firstterm>
|
||||||
<term>
|
is the process by which the backend server and
|
||||||
From the user shell
|
<application>postmaster</application>
|
||||||
</term>
|
ensure that the user requesting access to data is in fact who he/she
|
||||||
<listitem>
|
claims to be.
|
||||||
<para>
|
All users who invoke <Productname>Postgres</Productname> are checked against the
|
||||||
A backend server started from a user shell notes the user's (effective)
|
contents of the <literal>pg_user</literal> class to ensure that they are
|
||||||
user-id before performing a
|
authorized to do so. However, verification of the user's actual
|
||||||
<function>setuid</function>
|
identity is performed in a variety of ways:
|
||||||
to the user-id of user <replaceable>postgres</replaceable>.
|
|
||||||
The effective user-id is used
|
|
||||||
as the basis for access control checks. No other authentication is
|
|
||||||
conducted.
|
|
||||||
|
|
||||||
<varlistentry>
|
<variablelist>
|
||||||
<term>
|
<varlistentry>
|
||||||
From the network
|
<term>
|
||||||
</term>
|
From the user shell
|
||||||
<listitem>
|
</term>
|
||||||
<para>
|
<listitem>
|
||||||
If the <Productname>Postgres</Productname> system is built as distributed,
|
<para>
|
||||||
access to the Internet TCP port of the
|
A backend server started from a user shell notes the user's (effective)
|
||||||
<application>postmaster</application>
|
user-id before performing a
|
||||||
process is available to anyone. The DBA configures the pg_hba.conf file
|
<function>setuid</function>
|
||||||
in the PGDATA directory to specify what authentication system is to be used
|
to the user-id of user <replaceable>postgres</replaceable>.
|
||||||
according to the host making the connection and which database it is
|
The effective user-id is used
|
||||||
connecting to. See <citetitle>pg_hba.conf(5)</citetitle>
|
as the basis for access control checks. No other authentication is
|
||||||
for a description of the authentication
|
conducted.
|
||||||
systems available. Of course, host-based authentication is not fool-proof in
|
</para>
|
||||||
Unix, either. It is possible for determined intruders to also
|
</listitem>
|
||||||
masquerade the origination host. Those security issues are beyond the
|
</varlistentry>
|
||||||
scope of <Productname>Postgres</Productname>.
|
|
||||||
|
|
||||||
</variablelist>
|
<varlistentry>
|
||||||
|
<term>
|
||||||
|
From the network
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If the <Productname>Postgres</Productname> system is built as distributed,
|
||||||
|
access to the Internet TCP port of the
|
||||||
|
<application>postmaster</application>
|
||||||
|
process is available to anyone. The DBA configures the pg_hba.conf file
|
||||||
|
in the PGDATA directory to specify what authentication system is to be used
|
||||||
|
according to the host making the connection and which database it is
|
||||||
|
connecting to. See <citetitle>pg_hba.conf(5)</citetitle>
|
||||||
|
for a description of the authentication
|
||||||
|
systems available. Of course, host-based authentication is not fool-proof in
|
||||||
|
Unix, either. It is possible for determined intruders to also
|
||||||
|
masquerade the origination host. Those security issues are beyond the
|
||||||
|
scope of <Productname>Postgres</Productname>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1>
|
||||||
|
<title>User Names and Groups</title>
|
||||||
|
|
||||||
<Sect1>
|
<para>
|
||||||
<Title>Access Control</Title>
|
To define a new user, run the
|
||||||
|
<application>createuser</application> utility program.
|
||||||
|
</para>
|
||||||
|
|
||||||
<Para>
|
<para>
|
||||||
<Productname>Postgres</Productname> provides mechanisms to allow users
|
To assign a user or set of users to a new group, one must
|
||||||
to limit the access to their data that is provided to other users.
|
define the group itself, and assign users to that group. In
|
||||||
|
<application>Postgres</application> these steps are not currently
|
||||||
|
supported with a <command>create group</command> command. Instead,
|
||||||
|
the groups are defined by inserting appropriate values into the
|
||||||
|
<literal>pg_group</literal> system table, and then using the
|
||||||
|
<command>grant</command> command to assign privileges to the
|
||||||
|
group.
|
||||||
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<sect2>
|
||||||
<varlistentry>
|
<title>Creating Users</title>
|
||||||
<term>
|
|
||||||
Database superusers
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Database super-users (i.e., users who have <literal>pg_user.usesuper</literal>
|
|
||||||
set) silently bypass all of the access controls described below with
|
|
||||||
two exceptions: manual system catalog updates are not permitted if the
|
|
||||||
user does not have <literal>pg_user.usecatupd</literal> set, and destruction of
|
|
||||||
system catalogs (or modification of their schemas) is never allowed.
|
|
||||||
|
|
||||||
<varlistentry>
|
<para>
|
||||||
<term>
|
</para>
|
||||||
Access Privilege
|
</sect2>
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
The use of access privilege to limit reading, writing and setting
|
|
||||||
of rules on classes is covered in
|
|
||||||
<citetitle>grant/revoke(l)</citetitle>.
|
|
||||||
|
|
||||||
<varlistentry>
|
<sect2>
|
||||||
<term>
|
<title>Creating Groups</title>
|
||||||
Class removal and schema modification
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Commands that destroy or modify the structure of an existing class,
|
|
||||||
such as <command>alter</command>,
|
|
||||||
<command>drop table</command>,
|
|
||||||
and
|
|
||||||
<command>drop index</command>,
|
|
||||||
only operate for the owner of the class. As mentioned above, these
|
|
||||||
operations are <emphasis>never</emphasis>
|
|
||||||
permitted on system catalogs.
|
|
||||||
|
|
||||||
</variablelist>
|
<para>
|
||||||
|
Currently, there is no easy interface to set up user groups. You
|
||||||
|
have to explicitly insert/update the <literal>pg_group table</literal>.
|
||||||
|
For example:
|
||||||
|
|
||||||
<Sect1>
|
jolly=> insert into pg_group (groname, grosysid, grolist)
|
||||||
<Title>Functions and Rules</Title>
|
jolly=> values ('posthackers', '1234', '{5443, 8261}');
|
||||||
|
INSERT 548224
|
||||||
|
jolly=> grant insert on foo to group posthackers;
|
||||||
|
CHANGE
|
||||||
|
jolly=>
|
||||||
|
|
||||||
<Para>
|
The fields in pg_group are:
|
||||||
Functions and rules allow users to insert code into the backend server
|
* groname: the group name. This a name and should be purely
|
||||||
that other users may execute without knowing it. Hence, both
|
alphanumeric. Do not include underscores or other punctuation.
|
||||||
mechanisms permit users to <firstterm>trojan horse</firstterm>
|
* grosysid: the group id. This is an int4. This should be unique for
|
||||||
others with relative impunity. The only real protection is tight
|
each group.
|
||||||
control over who can define functions (e.g., write to relations with
|
* grolist: the list of pg_user id's that belong in the group. This
|
||||||
SQL fields) and rules. Audit trails and alerters on
|
is an int4[].
|
||||||
<literal>pg_class</literal>, <literal>pg_user</literal>
|
</para>
|
||||||
and <literal>pg_group</literal> are also recommended.
|
</sect2>
|
||||||
|
|
||||||
<Sect2>
|
<sect2>
|
||||||
<Title>Functions</Title>
|
<title>Assigning Users to Groups</title>
|
||||||
|
|
||||||
<Para>
|
<para>
|
||||||
Functions written in any language except SQL
|
</para>
|
||||||
run inside the backend server
|
</sect2>
|
||||||
process with the permissions of the user <replaceable>postgres</replaceable> (the
|
|
||||||
backend server runs with its real and effective user-id set to
|
|
||||||
<replaceable>postgres</replaceable>. It is possible for users to change the server's
|
|
||||||
internal data structures from inside of trusted functions. Hence,
|
|
||||||
among many other things, such functions can circumvent any system
|
|
||||||
access controls. This is an inherent problem with user-defined C functions.
|
|
||||||
|
|
||||||
<Sect2>
|
</sect1>
|
||||||
<Title>Rules</Title>
|
|
||||||
|
|
||||||
<Para>
|
<Sect1>
|
||||||
Like SQL functions, rules always run with the identity and
|
<Title>Access Control</Title>
|
||||||
permissions of the user who invoked the backend server.
|
|
||||||
|
|
||||||
<sect2>
|
<Para>
|
||||||
<title>
|
<Productname>Postgres</Productname> provides mechanisms to allow users
|
||||||
Caveats
|
to limit the access to their data that is provided to other users.
|
||||||
</title>
|
|
||||||
|
|
||||||
<para>
|
<variablelist>
|
||||||
There are no plans to explicitly support encrypted data inside of
|
<varlistentry>
|
||||||
<Productname>Postgres</Productname>
|
<term>
|
||||||
(though there is nothing to prevent users from encrypting
|
Database superusers
|
||||||
data within user-defined functions). There are no plans to explicitly
|
</term>
|
||||||
support encrypted network connections, either, pending a total rewrite
|
<listitem>
|
||||||
of the frontend/backend protocol.
|
<para>
|
||||||
<para>
|
Database super-users (i.e., users who have <literal>pg_user.usesuper</literal>
|
||||||
User names, group names and associated system identifiers (e.g., the
|
set) silently bypass all of the access controls described below with
|
||||||
contents of <literal>pg_user.usesysid</literal>) are assumed to be unique
|
two exceptions: manual system catalog updates are not permitted if the
|
||||||
throughout a database. Unpredictable results may occur if they are
|
user does not have <literal>pg_user.usecatupd</literal> set, and destruction of
|
||||||
not.
|
system catalogs (or modification of their schemas) is never allowed.
|
||||||
|
|
||||||
</chapter>
|
<varlistentry>
|
||||||
|
<term>
|
||||||
|
Access Privilege
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The use of access privilege to limit reading, writing and setting
|
||||||
|
of rules on classes is covered in
|
||||||
|
<citetitle>grant/revoke(l)</citetitle>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term>
|
||||||
|
Class removal and schema modification
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Commands that destroy or modify the structure of an existing class,
|
||||||
|
such as <command>alter</command>,
|
||||||
|
<command>drop table</command>,
|
||||||
|
and
|
||||||
|
<command>drop index</command>,
|
||||||
|
only operate for the owner of the class. As mentioned above, these
|
||||||
|
operations are <emphasis>never</emphasis>
|
||||||
|
permitted on system catalogs.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<Sect1>
|
||||||
|
<Title>Functions and Rules</Title>
|
||||||
|
|
||||||
|
<Para>
|
||||||
|
Functions and rules allow users to insert code into the backend server
|
||||||
|
that other users may execute without knowing it. Hence, both
|
||||||
|
mechanisms permit users to <firstterm>trojan horse</firstterm>
|
||||||
|
others with relative impunity. The only real protection is tight
|
||||||
|
control over who can define functions (e.g., write to relations with
|
||||||
|
SQL fields) and rules. Audit trails and alerters on
|
||||||
|
<literal>pg_class</literal>, <literal>pg_user</literal>
|
||||||
|
and <literal>pg_group</literal> are also recommended.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<Sect2>
|
||||||
|
<Title>Functions</Title>
|
||||||
|
|
||||||
|
<Para>
|
||||||
|
Functions written in any language except SQL
|
||||||
|
run inside the backend server
|
||||||
|
process with the permissions of the user <replaceable>postgres</replaceable> (the
|
||||||
|
backend server runs with its real and effective user-id set to
|
||||||
|
<replaceable>postgres</replaceable>. It is possible for users to change the server's
|
||||||
|
internal data structures from inside of trusted functions. Hence,
|
||||||
|
among many other things, such functions can circumvent any system
|
||||||
|
access controls. This is an inherent problem with user-defined C functions.
|
||||||
|
</para>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<Sect2>
|
||||||
|
<Title>Rules</Title>
|
||||||
|
|
||||||
|
<Para>
|
||||||
|
Like SQL functions, rules always run with the identity and
|
||||||
|
permissions of the user who invoked the backend server.
|
||||||
|
</para>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2>
|
||||||
|
<title>Caveats</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
There are no plans to explicitly support encrypted data inside of
|
||||||
|
<Productname>Postgres</Productname>
|
||||||
|
(though there is nothing to prevent users from encrypting
|
||||||
|
data within user-defined functions). There are no plans to explicitly
|
||||||
|
support encrypted network connections, either, pending a total rewrite
|
||||||
|
of the frontend/backend protocol.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
User names, group names and associated system identifiers (e.g., the
|
||||||
|
contents of <literal>pg_user.usesysid</literal>) are assumed to be unique
|
||||||
|
throughout a database. Unpredictable results may occur if they are
|
||||||
|
not.
|
||||||
|
</para>
|
||||||
|
</sect2>
|
||||||
|
</sect1>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
|
<!-- Keep this comment at the end of the file
|
||||||
|
Local variables:
|
||||||
|
mode: sgml
|
||||||
|
sgml-omittag:nil
|
||||||
|
sgml-shorttag:t
|
||||||
|
sgml-minimize-attributes:nil
|
||||||
|
sgml-always-quote-attributes:t
|
||||||
|
sgml-indent-step:1
|
||||||
|
sgml-indent-data:t
|
||||||
|
sgml-parent-document:nil
|
||||||
|
sgml-default-dtd-file:"./reference.ced"
|
||||||
|
sgml-exposed-tags:nil
|
||||||
|
sgml-local-catalogs:"/usr/lib/sgml/CATALOG"
|
||||||
|
sgml-local-ecat-files:nil
|
||||||
|
End:
|
||||||
|
-->
|
||||||
|
|||||||
Reference in New Issue
Block a user