Michael Paquier <michael.paqu...@gmail.com> writes:
> That will not sound much as a surprise as I spawned the original
> thread, but like Robert I understand that getting rid of all superuser
> checks is a goal that we are trying to reach to allow admins to have
> more flexibility in handling permissions to a subset of objects.
> Forcing an admin to give full superuser rights to one user willing to
> work only on LOs import and export is a wrong concept.

Right.  I think the question may boil down to how we document this.
The current para reads

    The server-side <function>lo_import</function> and
    <function>lo_export</function> 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.

I think as far as that goes, we can just change to "Therefore, by default
their use is restricted ...".  Then I suggest adding a <caution> para
after that, with wording along the lines of

    It is possible to GRANT use of server-side lo_import and lo_export 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 of this sort than full superuser privilege,
    as that helps to reduce the risk of damage from accidental errors.

We could expand that by mentioning the possibility of wrapper functions,
but it seems long enough already.


                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to