Stephen Frost <sfrost@snowman.net> writes:
> * Michael Paquier (michael.paquier@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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
