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. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers