Michael Paquier <michael.paquier@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,
usingthe 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
permissionsof 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
thesecurity 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
systemwithout bothering to obtain database superuser privileges as such. Access to roles having such privilege must
thereforebe guarded just as carefully as access to superuser roles. Nonetheless, if use of server-side lo_import
orlo_export is needed for some routine task, it's safer to use a role of this sort than full superuser privilege,
asthat 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.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
