On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > > Noah Misch <n...@leadboat.com> writes:
> > >> Let's look at the behavior of DDL-exposed access constraints for 
> > >> precedent. ?We
> > >> currently have three paradigms for applying access control to superusers:
> > >
> > >> 1. Settings that affect superusers and regular users identically. ?These 
> > >> include
> > >> ALTER ROLE ... LOGIN | VALID UNTIL.
> > >
> > >> 2. Rights that superusers possess implicitly and irrevocably; the actual 
> > >> setting
> > >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT 
> > >> ... ON
> > >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
> > >
> > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE 
> > >> ROLE
> > >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
> > >
> > >> I think we should merge #3 into #2; nothing about the REPLICATION setting
> > >> justifies a distinct paradigm.
> > >
> > > Yeah, there's much to be said for that. ?I thought the notion of a
> > > privilege that superusers might not have was pretty bogus to start with.
> 
> > That seems fine for 9.2, but I am still not in favor of changing the
> > behavior in back branches.  This is not such a confusing behavior that
> > we can't document our way out of it.
> > 
> > (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
> > and we can document our way out of that, this is small potatoes by
> > comparison.)
> 
> Quite so.  Let's do it that way.

Patch attached.

diff --git a/doc/src/sgml/high-availability.sgml 
b/doc/src/sgml/high-availability.sgml
index 86c2729..c5db6ef 100644
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 797,819 **** 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.
      </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
--- 797,810 ----
       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 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>
  
      <para>
       Client authentication for replication is controlled by a
       <filename>pg_hba.conf</> record specifying <literal>replication</> in the
diff --git a/doc/src/sgml/recovery-config.index 8647024..7e39c0d 100644
*** a/doc/src/sgml/recovery-config.sgml
--- b/doc/src/sgml/recovery-config.sgml
***************
*** 325,333 **** 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
            <xref linkend="streaming-replication-authentication">).
            A password needs to be provided too, if the primary demands password
            authentication.  It can be provided in the
--- 325,332 ----
            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 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
diff --git a/doc/src/sgml/ref/create_rolindex 4953df6..7ec4d0a 100644
*** a/doc/src/sgml/ref/create_role.sgml
--- b/doc/src/sgml/ref/create_role.sgml
***************
*** 185,192 **** 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.
         </para>
        </listitem>
       </varlistentry>
--- 185,191 ----
          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.
         </para>
        </listitem>
       </varlistentry>
diff --git a/doc/src/sgml/ref/pg_basebacindex 8c8c78f..05d5bed 100644
*** a/doc/src/sgml/ref/pg_basebackup.sgml
--- b/doc/src/sgml/ref/pg_basebackup.sgml
***************
*** 50,61 **** 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.
    </para>
  
    <para>
--- 50,62 ----
  
    <para>
     The backup is made over a regular <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 backup.
    </para>
  
    <para>
diff --git a/doc/src/sgml/ref/pg_receivexlindex 9a2a24b..fad7470 100644
*** a/doc/src/sgml/ref/pg_receivexlog.sgml
--- b/doc/src/sgml/ref/pg_receivexlog.sgml
***************
*** 50,62 **** 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.
    </para>
   </refsect1>
  
--- 50,62 ----
  
    <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 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>
  
diff --git a/doc/src/sgml/user-manag.sgml bindex 0a4f82d..177ac7a 100644
*** a/doc/src/sgml/user-manag.sgml
--- b/doc/src/sgml/user-manag.sgml
***************
*** 169,184 **** 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>.
         </para>
        </listitem>
       </varlistentry>
--- 169,179 ----
        <listitem>
         <para>
          A database superuser bypasses all permission checks, except the right
!         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,223 **** 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
          have <literal>LOGIN</> permission as well. To create such a role, use
          <literal>CREATE ROLE <replaceable>name</replaceable> REPLICATION
          LOGIN</literal>.
--- 212,219 ----
        <listitem>
         <para>
          A role must explicitly be given permission to initiate streaming
!         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>.
diff --git a/src/backend/commands/uindex fa312cb..797e957 100644
*** a/src/backend/commands/user.c
--- b/src/backend/commands/user.c
***************
*** 239,254 **** 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)
--- 239,245 ----
diff --git a/src/backend/utils/iniindex 94f92dd..37696c2 100644
*** a/src/backend/utils/init/postinit.c
--- b/src/backend/utils/init/postinit.c
***************
*** 659,669 **** 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())
                        ereport(FATAL,
                                        
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
!                                        errmsg("must be replication role to 
start walsender")));
  
                /* process any options passed in the startup packet */
                if (MyProcPort != NULL)
--- 659,668 ----
        {
                Assert(!bootstrap);
  
!               if (!superuser() && !is_authenticated_user_replication_role())
                        ereport(FATAL,
                                        
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
!                                        errmsg("must be superuser or 
replication role to start walsender")));
  
                /* process any options passed in the startup packet */
                if (MyProcPort != NULL)
-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to