Stephen Frost <sfr...@snowman.net> writes: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> Forcing an admin to give full superuser rights to one user willing to >> work only on LOs import and export is a wrong concept.
> The problem I have with this is that 'full superuser rights' actually > are being granted by this. You're able to read any file and write any > file on the filesystem that the PG OS user can. How is that not 'full > superuser rights'? It doesn't cause, say, "DELETE FROM pg_proc;" to succeed. You're still not getting the point that this is for people who want self-imposed restrictions. Sure, you can't give out lo_export privilege to someone you would not trust with superuser. But somebody who needs lo_export, and is trustworthy enough to have it, may still wish to do the inside-the-database part of their work with less than full superuser, just as a safety measure. It's the *exact same* reason why cautious people use "sudo" rather than just running as root all the time. > As I mentioned up-thread, if we want to make it so that non-superusers > can use lo_import/lo_export, then we should do that in a way that > allows the administrator to specify exactly the rights they really want > to give, based on a use-case for them. Our current answer for that is wrapper functions. This patch does not make that answer any less applicable than before. > I wonder what would happen if we allow this and then someone comes along > and re-proposes the 'CREATE DIRECTORY' concept that I had once proposed > (ideally with things cleaned up and tightened up to avoid there being > issues using it) to address the actual use-case for these functions to > be available to a non-superuser. We wouldn't be able to change these > functions to start checking the 'directory' rights or we would break > existing non-superuser usage of them. This is a straw man argument --- if we tighten up the function to check this as-yet-nonexistent feature, how is that not breaking existing use-cases anyway? 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