<!--  -->
<sect1 id="security">
<title>Security Considerations</title>

<para> The simplest and most common way of deploying &slony1; has been
to create a &slony1; database user account on all nodes in the system
and give that account database superuser privileges.  This allows
&slony1; to do <quote>anything it needs.</quote>
</para>

<para> In some environments, this is too much privilege to give out to
an automated system, so this section describes how to minimize the
privileges given out.</para>

<sect2> <title>Minimum Privileges</title>

<para>The minimum privileges for running each component of &slony1;
may be more specifically described.</para>

<variablelist>
<varlistentry><term>&lslonik;</term>
<listitem><para>
The slonik admin connections need to connect to the database as a database
superuser.  As part of the installation of &slony1;, the slonik program will
create C language functions in the database.  This requires superuser
access.  Some slonik commands will enable and disable indicies which by
manipulating pg_class.  This also requires superuser access.
</para></listitem></varlistentry>

<varlistentry><term>&lslon; Local Connection</term>

<listitem><para>
Each slon instance has a <quote>local</quote> database connection.  This is the database
connection that is specified on the either the slon command line or the
slon configuration file.</para>  

<para> Slon needs to connect to this database with considerable
<quote>write</quote> privileges, and requires superuser access in a couple of
places.</para>

<para> It must be able to 
<itemizedlist>

<listitem><para>Alter <envar>pg_class</envar> to deactivate indices when preparing to <command>COPY</command> a table</para></listitem>

<listitem><para>Make alterations to any of the &slony1; created tables
</para></listitem>
<listitem><para>Make modifications (INSERT/UPDATE/DELETE/ALTER) to all replicated tables.</para>
</listitem>
</itemizedlist>

</para>

</listitem></varlistentry>
<varlistentry>
<term>&lslon; Remote Connections</term>

<listitem><para> The Remote slon connection information is specified
in the <xref linkend="stmtstorepath"> command when adding paths.  The
&lslon; daemon needs to connect to remote databases with sufficient
permissions to:

<itemizedlist>

<listitem><para> SELECT from &slevent;</para></listitem>

<listitem><para> SELECT the &sllog1; and &sllog2; tables</para></listitem>

<listitem><para> SELECT any replicated tables that originate on the
remote node.  This is done as part of the initial <command>COPY</command> during the 
subscription process</para></listitem></itemizedlist>
</para>

<para> Note that this role does not have any need to modify data; it
purely involves <command>SELECT</command> access.</para>

</listitem>
</varlistentry>
</variablelist></sect2>

<sect2 id="superuser">
<title> Lowering Authority Usage from Superuser </title>

<para> Traditionally, it has been stated that <quote>&slony1; needs to
use superuser connections.</quote> It turns out that this is not
actually true, and and if there are particular concerns about
excessive use of superuser roles, it is possible to reduce the
<quote>security demands</quote> of &slony1; considerably. </para>

<para> It is <emphasis>simplest</emphasis> to have the replication
management user be a superuser, as, in that case, one need not think
about what permissions to configure, but this is excessive.</para>

<para> There is only actually one place where &slony1; truly requires
superuser access, and that is during the subscription process, as it
uses a <quote>hack</quote> to substantially improve performance,
updating the system catalogue directly to shut off indices during the
<command>COPY</command>.  This functionality is restricted to two
functions, as of version 2.1, with
<function>disable_indexes_on_table()</function> and
<function>enable_indexes_on_table()</function>, which may appropriate
superuser permissions if configured with <command>SECURITY
DEFINER</command>.  If these two functions are owned by a superuser,
then that is all the database superuser access that is
required. </para>

<para> One could set up a <quote>weak user</quote> assigned to all
&lslon; requests.  The minimal permissions that
this user, let's call it <command>weakuser</command>, requires are as
follows:</para>

<itemizedlist>

<listitem><para> It must have read access to the &slony1;-specific
namespace </para> </listitem>

<listitem><para> It must have read access to all tables and sequences
in that namespace</para> </listitem>

<listitem><para> It must have write access to the &slony1; table
<envar>sl_nodelock</envar> and sequence
<envar>sl_nodelock_nl_conncnt_seq</envar> </para> </listitem>

<listitem><para> At subscribe time, it must have read access to all of
the replicated tables. </para>

<para> Outside of subscription time, there is no need for access to
access to the replicated tables. </para> </listitem>

<listitem><para> There is some need for read access to tables in
pg_catalog; it has not been verified how little access would be
suitable. </para> </listitem>

<listitem><para> As mentioned, the functions for disabling and
re-enabling indexes during the subscription process must be owned by a
superuser, and must be accessible to the <quote>weak user.</quote>
</para></listitem>

</itemizedlist></sect2>

<sect2>
<title>Handling Database Authentication (Passwords)</title>
<para>
The slon and slonik programs connect to &postgres; as a normal &postgres;
client connection.  How &postgres authenticates the database connection
is controlled through the normal libpq authentication options via the
pg_hba.conf file.  See the &postgres; manual for full details. 
If you choose to require password authentication for &slony1; connections
then you have two options on where slon can obtain the passwords from.
<itemizedlist>
<listitem><para>You can store the passwords as part of the conninfo string
passed to the <xref linkend="stmtstorepath" > statement.  This means
that database passwords are stored inside of the database in cleartext.
</para></listitem>

<listitem><para>You can setup a .pgpass file on each node you are running
slon on.  slon will then retreive the passwords from the .pgpass file.
You must make sure that each node running slon have passwords for all
paths.
</para></listitem>

</itemizedlist>


</para>

</sect2>
<sect2> <title> Other Good Security Practices </title>

<para> In order to be able to clearly identify which logical roles are
being used, it seems advisable to set up users specifically for use by
replication, one or more <command>slony</command> users.</para>

<para> As already discussed, these users may have specific permissions
attached to indicate what capabilities they are intended to
have.</para>

<para> It is also useful for these users to be present so that system
monitoring and log monitoring processes are apprised of
<quote>who</quote> is doing things in the environment.</para></sect2>
</sect1>
<!-- 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:"slony.sgml"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->
