Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6d77652

Browse files
committed
Document changes in large-object privilege checking.
Commit5ecc0d7 removed the hard-wired superuser checks in lo_importand lo_export in favor of protecting them with SQL permissions, butfailed to adjust the documentation to match. Fix that, and add a<caution> paragraph pointing out the nontrivial security hazardsinvolved with actually granting such permissions. (It's still betterthan ALLOW_DANGEROUS_LO_FUNCTIONS, though.)Also, commitae20b23 caused large object read/write privilege tobe checked during lo_open() rather than in the actual read or writecalls. Document that.Discussion:https://postgr.es/m/CAB7nPqRHmNOYbETnc_2EjsuzSM00Z+BWKv9sy6tnvSd5gWT_JA@mail.gmail.com
1 parenta61f5ab commit6d77652

File tree

2 files changed

+38
-7
lines changed

2 files changed

+38
-7
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7540,9 +7540,6 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
75407540
Setting this variable does not disable all security checks related to
75417541
large objects &mdash; only those for which the default behavior has
75427542
changed in <productname>PostgreSQL</productname> 9.0.
7543-
For example, <literal>lo_import()</literal> and
7544-
<literal>lo_export()</literal> need superuser privileges regardless
7545-
of this setting.
75467543
</para>
75477544
</listitem>
75487545
</varlistentry>

‎doc/src/sgml/lobj.sgml

Lines changed: 38 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -292,6 +292,18 @@ int lo_open(PGconn *conn, Oid lobjId, int mode);
292292
modes for ordinary SQL <command>SELECT</command> commands.
293293
</para>
294294

295+
<para>
296+
<function>lo_open</function> will fail if <literal>SELECT</literal>
297+
privilege is not available for the large object, or
298+
if <symbol>INV_WRITE</symbol> is specified and <literal>UPDATE</literal>
299+
privilege is not available.
300+
(Prior to <productname>PostgreSQL</productname> 11, these privilege
301+
checks were instead performed at the first actual read or write call
302+
using the descriptor.)
303+
These privilege checks can be disabled with the
304+
<xref linkend="guc-lo-compat-privileges"> run-time parameter.
305+
</para>
306+
295307
<para>
296308
An example:
297309
<programlisting>
@@ -634,12 +646,34 @@ SELECT lo_export(image.raster, '/tmp/motd') FROM image
634646
<function>lo_export</function> functions behave considerably differently
635647
from their client-side analogs. These two functions read and write files
636648
in the server's file system, using the permissions of the database's
637-
owning user. Therefore, their use is restricted to superusers. In
638-
contrast, the client-side import and export functions read and write files
639-
in the client's file system, using the permissions of the client program.
640-
The client-side functions do not require superuser privilege.
649+
owning user. Therefore, by default their use is restricted to superusers.
650+
In contrast, the client-side import and export functions read and write
651+
files in the client's file system, using the permissions of the client
652+
program. The client-side functions do not require any database
653+
privileges, except the privilege to read or write the large object in
654+
question.
641655
</para>
642656

657+
<caution>
658+
<para>
659+
It is possible to <xref linkend="sql-grant"> use of the
660+
server-side <function>lo_import</function>
661+
and <function>lo_export</function> functions to non-superusers, but
662+
careful consideration of the security implications is required. A
663+
malicious user of such privileges could easily parlay them into becoming
664+
superuser (for example by rewriting server configuration files), or could
665+
attack the rest of the server's file system without bothering to obtain
666+
database superuser privileges as such. <emphasis>Access to roles having
667+
such privilege must therefore be guarded just as carefully as access to
668+
superuser roles.</emphasis> Nonetheless, if use of
669+
server-side <function>lo_import</function>
670+
or <function>lo_export</function> is needed for some routine task, it's
671+
safer to use a role with such privileges than one with full superuser
672+
privileges, as that helps to reduce the risk of damage from accidental
673+
errors.
674+
</para>
675+
</caution>
676+
643677
<para>
644678
The functionality of <function>lo_read</function> and
645679
<function>lo_write</function> is also available via server-side calls,

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp