Skip to content

P
Postgres FD Implementation
Commit 22890097 authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

Clean up markup for first useful version.

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