Make superuser imply replication privilege. The idea of a privilege that

superuser doesn't have doesn't make much sense, as a superuser can do
whatever he wants through other means, anyway. So instead of granting
replication privilege to superusers in CREATE USER time by default, allow
replication connection from superusers whether or not they have the
replication privilege.

Patch by Noah Misch, per discussion on bug report #6264
This commit is contained in:
Heikki Linnakangas 2012-01-14 18:22:16 +02:00
parent ea038d65c2
commit 00c5f55061
8 changed files with 32 additions and 56 deletions

View File

@ -797,23 +797,14 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
It is very important that the access privileges for replication be set up
so that only trusted users can read the WAL stream, because it is
easy to extract privileged information from it. Standby servers must
authenticate to the primary as an account that has the
<literal>REPLICATION</> privilege. So a role with the
<literal>REPLICATION</> and <literal>LOGIN</> privileges needs to be
created on the primary.
authenticate to the primary as a superuser or an account that has the
<literal>REPLICATION</> privilege. It is recommended to create a
dedicated user account with <literal>REPLICATION</> and <literal>LOGIN</>
privileges for replication. While <literal>REPLICATION</> privilege gives
very high permissions, it does not allow the user to modify any data on
the primary system, which the <literal>SUPERUSER</> privilege does.
</para>
<note>
<para>
It is recommended that a dedicated user account is used for replication.
While the <literal>REPLICATION</> privilege is granted to superuser
accounts by default, it is not recommended to use superuser accounts
for replication. While <literal>REPLICATION</> privilege gives very high
permissions, it does not allow the user to modify any data on the
primary system, which the <literal>SUPERUSER</> privilege does.
</para>
</note>
<para>
Client authentication for replication is controlled by a
<filename>pg_hba.conf</> record specifying <literal>replication</> in the

View File

@ -325,9 +325,8 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
The connection string should specify the host name (or address)
of the primary server, as well as the port number if it is not
the same as the standby server's default.
Also specify a user name corresponding to a role that has the
<literal>REPLICATION</> and <literal>LOGIN</> privileges on the
primary (see
Also specify a user name corresponding to a suitably-privileged role
on the primary (see
<xref linkend="streaming-replication-authentication">).
A password needs to be provided too, if the primary demands password
authentication. It can be provided in the

View File

@ -185,8 +185,7 @@ CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replac
A role having the <literal>REPLICATION</> attribute is a very
highly privileged role, and should only be used on roles actually
used for replication. If not specified,
<literal>NOREPLICATION</literal> is the default for all roles except
superusers.
<literal>NOREPLICATION</literal> is the default.
</para>
</listitem>
</varlistentry>

View File

@ -50,12 +50,13 @@ PostgreSQL documentation
<para>
The backup is made over a regular <productname>PostgreSQL</productname>
connection, and uses the replication protocol. The connection must be
made with a user having <literal>REPLICATION</literal> permissions (see
<xref linkend="role-attributes">), and the user must be granted explicit
permissions in <filename>pg_hba.conf</filename>. The server must also
be configured with <xref linkend="guc-max-wal-senders"> set high enough
to leave at least one session available for the backup.
connection, and uses the replication protocol. The connection must be made
with a superuser or a user having <literal>REPLICATION</literal>
permissions (see <xref linkend="role-attributes">),
and <filename>pg_hba.conf</filename> must explicitly permit the replication
connection. The server must also be configured
with <xref linkend="guc-max-wal-senders"> set high enough to leave at least
one session available for the backup.
</para>
<para>

View File

@ -50,13 +50,13 @@ PostgreSQL documentation
<para>
The transaction log is streamed over a regular
<productname>PostgreSQL</productname> connection, and uses the
replication protocol. The connection must be
made with a user having <literal>REPLICATION</literal> permissions (see
<xref linkend="role-attributes">), and the user must be granted explicit
permissions in <filename>pg_hba.conf</filename>. The server must also
be configured with <xref linkend="guc-max-wal-senders"> set high enough
to leave at least one session available for the stream.
<productname>PostgreSQL</productname> connection, and uses the replication
protocol. The connection must be made with a superuser or a user
having <literal>REPLICATION</literal> permissions (see
<xref linkend="role-attributes">), and <filename>pg_hba.conf</filename>
must explicitly permit the replication connection. The server must also be
configured with <xref linkend="guc-max-wal-senders"> set high enough to
leave at least one session available for the stream.
</para>
</refsect1>

View File

@ -169,16 +169,11 @@ CREATE USER <replaceable>name</replaceable>;
<listitem>
<para>
A database superuser bypasses all permission checks, except the right
to log in or the right to initiate replication. This is a
dangerous privilege and should not be used carelessly; it is best
to do most of your work as a role that is not a superuser.
To create a new database superuser, use <literal>CREATE ROLE
<replaceable>name</replaceable> SUPERUSER</literal>. You must do
this as a role that is already a superuser. Creating a superuser
will by default also grant permissions to initiate streaming
replication. For increased security this can be disallowed using
<literal>CREATE ROLE <replaceable>name</replaceable> SUPERUSER
NOREPLICATION</literal>.
to log in. This is a dangerous privilege and should not be used
carelessly; it is best to do most of your work as a role that is not a
superuser. To create a new database superuser, use <literal>CREATE
ROLE <replaceable>name</replaceable> SUPERUSER</literal>. You must do
this as a role that is already a superuser.
</para>
</listitem>
</varlistentry>
@ -217,7 +212,8 @@ CREATE USER <replaceable>name</replaceable>;
<listitem>
<para>
A role must explicitly be given permission to initiate streaming
replication. A role used for streaming replication must always
replication (except for superusers, since those bypass all permission
checks). A role used for streaming replication must always
have <literal>LOGIN</> permission as well. To create such a role, use
<literal>CREATE ROLE <replaceable>name</replaceable> REPLICATION
LOGIN</literal>.

View File

@ -239,16 +239,7 @@ CreateRole(CreateRoleStmt *stmt)
if (dpassword && dpassword->arg)
password = strVal(dpassword->arg);
if (dissuper)
{
issuper = intVal(dissuper->arg) != 0;
/*
* Superusers get replication by default, but only if NOREPLICATION
* wasn't explicitly mentioned
*/
if (issuper && !(disreplication && intVal(disreplication->arg) == 0))
isreplication = 1;
}
if (dinherit)
inherit = intVal(dinherit->arg) != 0;
if (dcreaterole)

View File

@ -659,11 +659,10 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
{
Assert(!bootstrap);
/* must have authenticated as a replication role */
if (!is_authenticated_user_replication_role())
if (!superuser() && !is_authenticated_user_replication_role())
ereport(FATAL,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("must be replication role to start walsender")));
errmsg("must be superuser or replication role to start walsender")));
/* process any options passed in the startup packet */
if (MyProcPort != NULL)