@@ -3001,20 +3001,18 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
3001
3001
<para>
3002
3002
By default, users cannot access any objects in schemas they do not
3003
3003
own. To allow that, the owner of the schema must grant the
3004
- <literal>USAGE</literal> privilege on the schema. To allow users
3005
- to make use of the objects in the schema, additional privileges
3006
- might need to be granted, as appropriate for the object.
3004
+ <literal>USAGE</literal> privilege on the schema. By default, everyone
3005
+ has that privilege on the schema <literal>public</literal>. To allow
3006
+ users to make use of the objects in a schema, additional privileges might
3007
+ need to be granted, as appropriate for the object.
3007
3008
</para>
3008
3009
3009
3010
<para>
3010
- A user can also be allowed to create objects in someone else's
3011
- schema. To allow that, the <literal>CREATE</literal> privilege on
3012
- the schema needs to be granted. Note that by default, everyone
3013
- has <literal>CREATE</literal> and <literal>USAGE</literal> privileges on
3014
- the schema
3015
- <literal>public</literal>. This allows all users that are able to
3016
- connect to a given database to create objects in its
3017
- <literal>public</literal> schema.
3011
+ A user can also be allowed to create objects in someone else's schema. To
3012
+ allow that, the <literal>CREATE</literal> privilege on the schema needs to
3013
+ be granted. In databases upgraded from
3014
+ <productname>PostgreSQL</productname> 14 or earlier, everyone has that
3015
+ privilege on the schema <literal>public</literal>.
3018
3016
Some <link linkend="ddl-schemas-patterns">usage patterns</link> call for
3019
3017
revoking that privilege:
3020
3018
<programlisting>
@@ -3087,20 +3085,25 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
3087
3085
database owner attack. -->
3088
3086
<para>
3089
3087
Constrain ordinary users to user-private schemas. To implement this,
3090
- issue <literal>REVOKE CREATE ON SCHEMA public FROM PUBLIC</literal>,
3091
- and create a schema foreach userwith the same name as that user.
3092
- Recall that thedefault search path starts
3093
- with <literal>$user</literal>, which resolves to the user name.
3094
- Therefore, if each user has a separate schema, they access their own
3095
- schemas by default. After adopting this pattern in a database where
3096
- untrusted users had already logged in, consider auditing the public
3097
- schema for objects named like objects in
3088
+ first issue <literal>REVOKE CREATE ON SCHEMA public FROM
3089
+ PUBLIC</literal>. Then, forevery userneeding to create non-temporary
3090
+ objects, create a schema with thesame name as that user. Recall that
3091
+ the default search path starts with <literal>$user</literal>, which
3092
+ resolves to the user name. Therefore, if each user has a separate
3093
+ schema, they access their own schemas by default. After adopting this
3094
+ pattern in a database where untrusted users had already logged in,
3095
+ consider auditing the public schema for objects named like objects in
3098
3096
schema <literal>pg_catalog</literal>. This pattern is a secure schema
3099
3097
usage pattern unless an untrusted user is the database owner or holds
3100
3098
the <literal>CREATEROLE</literal> privilege, in which case no secure
3101
3099
schema usage pattern exists.
3102
3100
</para>
3103
3101
<para>
3102
+ If the database originated in an upgrade
3103
+ from <productname>PostgreSQL</productname> 14 or earlier,
3104
+ the <literal>REVOKE</literal> is essential. Otherwise, the default
3105
+ configuration follows this pattern; ordinary users can create only
3106
+ temporary objects until a privileged user furnishes a schema.
3104
3107
</para>
3105
3108
</listitem>
3106
3109
@@ -3109,10 +3112,10 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
3109
3112
Remove the public schema from the default search path, by modifying
3110
3113
<link linkend="config-setting-configuration-file"><filename>postgresql.conf</filename></link>
3111
3114
or by issuing <literal>ALTER ROLE ALL SET search_path =
3112
- "$user"</literal>.Everyone retains the ability to createobjects in
3113
- the public schema, but only qualified names will choosethose objects.
3114
- While qualified table references are fine, calls to functions in the
3115
- public schema <link linkend="typeconv-func">will be unsafe or
3115
+ "$user"</literal>.Then, grant privileges to createin the public
3116
+ schema. Only qualified names will choosepublic schema objects. While
3117
+ qualified table references are fine, calls to functions in the public
3118
+ schema <link linkend="typeconv-func">will be unsafe or
3116
3119
unreliable</link>. If you create functions or extensions in the public
3117
3120
schema, use the first pattern instead. Otherwise, like the first
3118
3121
pattern, this is secure unless an untrusted user is the database owner
@@ -3122,11 +3125,14 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
3122
3125
3123
3126
<listitem>
3124
3127
<para>
3125
- Keep the default. All users access the public schema implicitly. This
3128
+ Keep the default search path, and grant privileges to create in the
3129
+ public schema. All users access the public schema implicitly. This
3126
3130
simulates the situation where schemas are not available at all, giving
3127
3131
a smooth transition from the non-schema-aware world. However, this is
3128
3132
never a secure pattern. It is acceptable only when the database has a
3129
- single user or a few mutually-trusting users.
3133
+ single user or a few mutually-trusting users. In databases upgraded
3134
+ from <productname>PostgreSQL</productname> 14 or earlier, this is the
3135
+ default.
3130
3136
</para>
3131
3137
</listitem>
3132
3138
</itemizedlist>