Mise à jour en version 10.3

postgresql/config.xml

@@ -6469,11 +6469,6 @@ Ces paramètres contrôlent le comportement de la fonctionnalité appelée
     requêtes apparaissant dans <varname>search_path</varname> sont
     résolues.
    </para>
-
-   <para>
-    Pour plus d'informations sur la gestion des schémas, voir la
-    <xref linkend="ddl-schemas"/>.
-   </para>
   </listitem>
  </varlistentry>
 
@@ -7506,6 +7501,14 @@ SET XML OPTION { DOCUMENT | CONTENT };
 <programlisting>dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'</programlisting>
          </para>
 
+       <para>
+        Pour plus d'informations sur la gestion des schémas, voir <xref
+        linkend="ddl-schemas"/>. En particulier, la configuration par défaut
+        est seulement convenable quand la base de données a un seul
+        utilisateur ou quelques utilisateurs qui se font confiance
+        mutuellement.
+       </para>
+
        <para>
         La valeur par défaut de ce paramètre est <literal>'$libdir'</literal>.
         Si la valeur est une chaîne vide, la recherche automatique du chemin est

postgresql/contrib.xml

@@ -75,9 +75,9 @@ CREATE EXTENSION <replaceable>nom_module</replaceable>;
  <para>
   Beaucoup de modules vous permettent d'installer leurs objets dans le schéma
   de votre choix. Pour cela, ajoutez <literal>SCHEMA
-   <replaceable>nom_schéma</replaceable></literal> à la commande <command>CREATE
-   EXTENSION</command>. Par défaut, les objets seront placés dans le schéma
-  de création par défaut, donc généralement <literal>public</literal>.
+  <replaceable>nom_schéma</replaceable></literal> à la commande <command>CREATE
+  EXTENSION</command>. Par défaut, les objets seront placés dans le schéma
+  de création par défaut, qui est par défaut <literal>public</literal>.
  </para>
 
  <para>

postgresql/dblink.xml

@@ -86,7 +86,7 @@
        Chaîne de connexion au format standard de la
        <application>libpq</application>, par exemple
        <literal>hostaddr=127.0.0.1 port=5432 dbname=mabase user=postgres
-        password=monmotdepasse</literal>.
+        password=monmotdepasse options=-csearch_path=</literal>.
        Pour les détails, voir <xref linkend="libpq-connstring"/>.
        Sinon, il est possible de donner le nom d'un serveur distant.
       </para>
@@ -107,6 +107,19 @@
   <refsect1>
    <title>Notes</title>
 
+   <para>
+    Si des utilisateurs non dignes de confiance, ont accès à
+    une base de données qui n'a pas adoptée une <link
+    linkend="ddl-schemas-patterns">méthode sécurisée d'usage des
+    schémas</link>, commencez chaque session en supprimant les schémas
+    modifiables par tout le monde du paramètre <varname>search_path</varname>.
+    Par exemple, un utilisateur pourrait ajouter
+    <literal>options=-csearch_path=</literal> au
+    <parameter>connstr</parameter>. Cette considération n'est pas spécifique à
+    <filename>dblink</filename>&nbsp;; elle s'applique à toute interface
+    permettant d'exécuter des commandes SQL arbitraires.
+   </para>
+
    <para>
     Seuls les super-utilisateurs peuvent utiliser
     <function>dblink_connect</function> pour créer des connexions authentifiées
@@ -126,13 +139,13 @@
    <title>Exemple</title>
 
    <screen>
-SELECT dblink_connect('dbname=postgres');
+SELECT dblink_connect('dbname=postgres options=-csearch_path=');
   dblink_connect
  ----------------
   OK
  (1 row)
 
- SELECT dblink_connect('myconn', 'dbname=postgres');
+ SELECT dblink_connect('myconn', 'dbname=postgres options=-csearch_path=');
   dblink_connect
  ----------------
   OK
@@ -428,7 +441,8 @@ SELECT dblink_disconnect();
 
     <programlisting>
 SELECT *
-    FROM dblink('dbname=mydb', 'select proname, prosrc from pg_proc')
+    FROM dblink('dbname=mydb options=-csearch_path=',
+                'select proname, prosrc from pg_proc')
       AS t1(proname name, prosrc text)
     WHERE proname LIKE 'bytea%';
     </programlisting>
@@ -464,7 +478,8 @@ SELECT *
     <programlisting>
 CREATE VIEW myremote_pg_proc AS
   SELECT *
-    FROM dblink('dbname=postgres', 'select proname, prosrc from pg_proc')
+    FROM dblink('dbname=postgres options=-csearch_path=',
+                'select proname, prosrc from pg_proc')
     AS t1(proname name, prosrc text);
 
 SELECT * FROM myremote_pg_proc WHERE proname LIKE 'bytea%';
@@ -476,7 +491,8 @@ SELECT * FROM myremote_pg_proc WHERE proname LIKE 'bytea%';
    <title>Exemple</title>
 
    <screen>
-SELECT * FROM dblink('dbname=postgres', 'select proname, prosrc from pg_proc')
+SELECT * FROM dblink('dbname=postgres options=-csearch_path=',
+                     'select proname, prosrc from pg_proc')
   AS t1(proname name, prosrc text) WHERE proname LIKE 'bytea%';
   proname   |   prosrc
 ------------+------------
@@ -518,7 +534,7 @@ SELECT * FROM dblink('select proname, prosrc from pg_proc')
  byteaout   | byteaout
 (12 rows)
 
-SELECT dblink_connect('myconn', 'dbname=regression');
+SELECT dblink_connect('myconn', 'dbname=regression options=-csearch_path=');
  dblink_connect
 ----------------
  OK
@@ -800,7 +816,7 @@ DETAIL:  ERROR:  null value in column "relnamespace" violates not-null constrain
    <title>Exemple</title>
 
    <screen>
-SELECT dblink_connect('dbname=postgres');
+SELECT dblink_connect('dbname=postgres options=-csearch_path=');
  dblink_connect
 ----------------
  OK
@@ -925,7 +941,7 @@ SELECT dblink_open('foo', 'select proname, prosrc from pg_proc');
    <title>Exemple</title>
 
    <screen>
-SELECT dblink_connect('dbname=postgres');
+SELECT dblink_connect('dbname=postgres options=-csearch_path=');
  dblink_connect
 ----------------
  OK
@@ -1064,7 +1080,7 @@ SELECT * FROM dblink_fetch('foo', 5) AS (funcname name, source text);
    <title>Exemple</title>
 
    <screen>
-SELECT dblink_connect('dbname=postgres');
+SELECT dblink_connect('dbname=postgres options=-csearch_path=');
  dblink_connect
 ----------------
  OK

postgresql/ddl.xml

@@ -2182,6 +2182,22 @@ SELECT * FROM information WHERE groupe_id = 2 FOR UPDATE;
     correspond dans d'autres schémas de la base.
    </para>
 
+   <para>
+    La possibilité de créer des objets de même nom dans différents schémas
+    complique l'écriture d'une requête qui référence précisément les mêmes
+    objets à chaque fois. Cela ouvre aussi la possibilité aux utilisateurs de
+    modifier le comportement des requêtes des autres utilisations, par
+    accident ou volontairement. À cause de la prévalence des noms non
+    qualifiés dans les requêtes et de leur utilisation des internes de
+    <productname>PostgreSQL</productname>, ajouter un schéma à
+    <varname>search_path</varname> demande en effet à tous les utilisateurs
+    d'avoir le droit <literal>CREATE</literal> sur ce schéma. Quand vous
+    exécutez une requête ordinaire, un utilisateur mal intentionné capable de
+    créer des objets dans un schéma de votre chemin de recherche peut prendre
+    contrôle et exécuter des fonctions SQL arbitraire comme si vous les
+    exécutiez.
+   </para>
+
    <indexterm>
     <primary>schéma</primary>
     <secondary>courant</secondary>
@@ -2286,8 +2302,9 @@ SELECT * FROM information WHERE groupe_id = 2 FOR UPDATE;
     <literal>USAGE</literal> sur le schéma <literal>public</literal>.
     Cela permet à tous les utilisateurs qui peuvent se connecter
     à une base de données de créer des objets dans son schéma
-    <literal>public</literal>. Si cela ne doit pas être le cas, ce privilège
-    peut être révoqué&nbsp;:
+    <literal>public</literal>.
+    Certaines <link linkend="ddl-schemas-patterns">méthodes d'usage</link>
+    demandent à révoquer ce droit&nbsp;:
 <programlisting>REVOKE CREATE ON SCHEMA public FROM PUBLIC;</programlisting>
     Le premier <quote>public</quote> est le schéma, le second
     <quote>public</quote> signifie <quote>tout utilisateur</quote>. Dans le
@@ -2335,53 +2352,88 @@ SELECT * FROM information WHERE groupe_id = 2 FOR UPDATE;
    <title>Utilisation</title>
 
    <para>
-    Les schémas peuvent être utilisés de différentes façons pour organiser
-    les données. Certaines d'entre elles, recommandées, sont facilement supportés par la
-    configuration par défaut&nbsp;:
+    Les schémas peuvent être utilisés de différentes façons pour organiser les
+    données. Il existe quelques méthodes facilement supportées par la
+    configuration par défaut, dont une seule est suffisant lorsque les
+    utilisateurs de l'instance ne font pas confiance aux autres
+    utilisateurs&nbsp;:
     <itemizedlist>
+     <!-- "DROP SCHEMA public" is inferior to this REVOKE, because pg_dump
+          doesn't preserve that DROP. -->
      <listitem>
       <para>
-       si aucun schéma n'est créé, alors tous les utilisateurs
-       ont implicitement accès au schéma public. Cela permet de simuler une
-       situation dans laquelle les schémas ne sont pas disponibles.
-       Cette situation est essentiellement recommandée lorsqu'il n'y a qu'un
-       utilisateur, ou un très petit nombre d'utilisateurs qui coopèrent au
-       sein d'une base de données. Cette configuration permet aussi d'opérer
-       une transition en douceur depuis un monde où les schémas sont inconnus&nbsp;;
+       Contraindre les utilisateurs ordinaires aux schémas privés des
+       utilisateurs. Pour cela, exécutez <literal>REVOKE CREATE ON SCHEMA
+       public FROM PUBLIC</literal>, et créez un schéma pour chaque
+       utilisateur, du nom de cet utilisateur. Si les utilisateurs affectés se
+       sont déjà connectés avant cette opération, pensez à réaliser un audit
+       du schéma public en recherchant des objets de même nom que ceux du
+       schéma <literal>pg_catalog</literal>. Rappelez-vous que le chemin de
+       recherche par défaut commence avec <literal>$user</literal>, qui est
+       remplacé par le nom de l'utilisateur. De ce fait, si chaque utilisateur
+       a un schéma séparé, ils accèdent à leur propre schéma par défaut.
       </para>
      </listitem>
 
      <listitem>
       <para>
-       pour chaque utilisateur, un schéma, de nom identique à celui de
-       l'utilisateur, peut être créé. Le chemin de recherche par défaut
-       commence par <literal>$user</literal>, soit le nom de l'utilisateur.
-       Si tous les utilisateurs disposent d'un schéma distinct, ils accèdent, par
-       défaut, à leur propre schéma.
-     <!--  </para>
-
-      <para> -->
-         Dans cette configuration, il est possible de révoquer l'accès
-         au schéma public (voire de supprimer ce schéma)
-         pour confiner les utilisateurs dans leur propre schéma&nbsp;;
-        </para>
-       </listitem>
+       Supprimer le schéma public de chaque chemin de recherche par défaut des
+       utilisateurs en exécutant <literal>ALTER ROLE
+       <replaceable>utilisateur</replaceable> SET search_path =
+       "$utilisateur"</literal>. Tous conservent la possibilité de créer des
+       objets dans le schéma public mais seuls les noms qualifiés choisiront
+       ces objets. Un utilisant disposant de l'attribut
+       <literal>CREATEROLE</literal> peut enlever cette configuration et
+       exécuter n'importe quel requête sous l'identité des utilisateurs se
+       basant sur cette configuration. Si vous donnez l'attribut
+       <literal>CREATEROLE</literal> à des utilisateurs sans garantie sur
+       cette capacité pratiquement équivalente à l'attribut superutilisateur,
+       utilisez plutôt la première méthode.
+      </para>
+     </listitem>
 
-       <listitem>
-        <para>
-         l'installation d'applications partagées (tables utilisables
-         par tout le monde, fonctionnalités supplémentaires fournies par
-         des applications tiers, etc) peut se faire dans des schémas distincts.
-         Il faut alors accorder des privilèges appropriés
-         pour permettre aux autres utilisateurs d'y accéder. Les utilisateurs
-         peuvent alors se référer à ces objets additionnels en qualifiant
-         leur nom du nom de schéma ou ajouter les schémas
-         supplémentaires dans leur chemin de recherche, au choix.
-        </para>
-       </listitem>
-      </itemizedlist>
-     </para>
-    </sect2>
+     <listitem>
+      <para>
+       Supprimer le schéma public du <varname>search_path</varname> dans <link
+       linkend="config-setting-configuration-
+       file"><filename>postgresql.conf</filename></link>. La conséquence pour
+       l'utilisateur correspond à celle de la méthode précédente. En plus des
+       implications pour le <literal>CREATEROLE</literal>, cela demande de
+       faire confiance aux propriétaires des bases de données de la même
+       façon. Si vous affectez l'attribut <literal>CREATEROLE</literal>,
+       l'attribut <literal>CREATEDB</literal> ou la propriété d'une base de
+       données à des utilisateurs sans garantie sur cette capacité
+       pratiquement équivalente à l'attribut superutilisateur, utilisez plutôt
+       la première méthode.
+      </para>
+     </listitem>
+
+     <listitem>
+      <para>
+       Conserver la valeur par défaut. Tous les utilisateurs ont accès au
+       schéma public implicitement. Ceci simule la situation où les schémas ne
+       sont pas du tout disponibles, réalisant ainsi une transition tranquille
+       vers un monde qui ne connait pas les schémas. Néanmoins, tout
+       utilisateur peut exécuter des requêtes arbitraires sous l'identité
+       d'utilisateur qui ne se protège pas individuellement. Cette méthode est
+       seulement acceptable quand la base de données n'a qu'un seul
+       utilisateur ou peu d'utilisateurs mais qui se font confiance.
+      </para>
+     </listitem>
+    </itemizedlist>
+   </para>
+
+   <para>
+    Pour chaque méthode, pour installer des applications partagées (tables
+    utilisées par tout le monde, fonctions supplémentaires fournies par des
+    tiers, etc.), placez les dans des schémas séparés. Rappelez-vous de donner
+    les droits appropriés pour permettre aux autres utilisateurs d'y accéder.
+    Les utilisateurs peuvent ensuite faire référence à ces objets
+    supplémentaires en les qualifiant avec le nom du schéma ou ils peuvent
+    placer les schémas supplémentaires dans leur chemin de recherche, suivant
+    leur préférence.
+   </para>
+  </sect2>
 
     <sect2 id="ddl-schemas-portability">
      <title>Portabilité</title>
@@ -2404,8 +2456,7 @@ SELECT * FROM information WHERE groupe_id = 2 FOR UPDATE;
      <para>
       Le concept de schéma <literal>public</literal> n'existe pas non plus dans le
       standard SQL. Pour plus de conformité au standard, le schéma
-      <literal>public</literal> ne devrait pas être utilisé (voire être
-      supprimé).
+      <literal>public</literal> ne devrait pas être utilisé.
      </para>
 
      <para>