Document changes in large-object privilege checking.

Commit 5ecc0d738 removed the hard-wired superuser checks in lo_import
and lo_export in favor of protecting them with SQL permissions, but
failed to adjust the documentation to match.  Fix that, and add a
 paragraph pointing out the nontrivial security hazards
involved with actually granting such permissions.  (It's still better
than ALLOW_DANGEROUS_LO_FUNCTIONS, though.)

Also, commit ae20b23a9 caused large object read/write privilege to
be checked during lo_open() rather than in the actual read or write
calls.  Document that.

Discussion: https://postgr.es/m/CAB7nPqRHmNOYbETnc_2EjsuzSM00Z+BWKv9sy6tnvSd5gWT_JA@mail.gmail.com

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d360fc4d58a154848b548ab10e286349ea716779..996e82534abae6d9c9d4e41ec3a8ead7b5e39991 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7540,9 +7540,6 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
         Setting this variable does not disable all security checks related to
         large objects — only those for which the default behavior has
         changed in PostgreSQL 9.0.
-        For example, lo_import() and
-        lo_export() need superuser privileges regardless
-        of this setting.
        
       
      

diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml
index c743b5c0baa7f9035299ef683f07981a33ab939b..e11c8e0f8b1829885fefd4542b56580e218b4142 100644 (file)
--- a/doc/src/sgml/lobj.sgml
+++ b/doc/src/sgml/lobj.sgml
@@ -292,6 +292,18 @@ int lo_open(PGconn *conn, Oid lobjId, int mode);
      modes for ordinary SQL SELECT commands.
     
 
+    
+     lo_open will fail if SELECT
+     privilege is not available for the large object, or
+     if INV_WRITE is specified and UPDATE
+     privilege is not available.
+     (Prior to PostgreSQL 11, these privilege
+     checks were instead performed at the first actual read or write call
+     using the descriptor.)
+     These privilege checks can be disabled with the
+      run-time parameter.
+    
+
     
      An example:
 
@@ -634,12 +646,34 @@ SELECT lo_export(image.raster, '/tmp/motd') FROM image
     lo_export functions behave considerably differently
     from their client-side analogs.  These two functions read and write files
     in the server's file system, using the permissions of the database's
-    owning user.  Therefore, their use is restricted to superusers.  In
-    contrast, the client-side import and export functions read and write files
-    in the client's file system, using the permissions of the client program.
-    The client-side functions do not require superuser privilege.
+    owning user.  Therefore, by default their use is restricted to superusers.
+    In contrast, the client-side import and export functions read and write
+    files in the client's file system, using the permissions of the client
+    program.  The client-side functions do not require any database
+    privileges, except the privilege to read or write the large object in
+    question.
   
 
+  
+   
+    It is possible to  use of the
+    server-side lo_import
+    and lo_export functions to non-superusers, but
+    careful consideration of the security implications is required.  A
+    malicious user of such privileges could easily parlay them into becoming
+    superuser (for example by rewriting server configuration files), or could
+    attack the rest of the server's file system without bothering to obtain
+    database superuser privileges as such.  Access to roles having
+    such privilege must therefore be guarded just as carefully as access to
+    superuser roles.  Nonetheless, if use of
+    server-side lo_import
+    or lo_export is needed for some routine task, it's
+    safer to use a role with such privileges than one with full superuser
+    privileges, as that helps to reduce the risk of damage from accidental
+    errors.
+   
+  
+
   
     The functionality of lo_read and
     lo_write is also available via server-side calls,