On Tue, Apr 2, 2019 at 11:31 AM Andres Freund <andres@xxxxxxxxxxx> wrote:
Hi,
On 2019-04-02 07:35:02 -0500, Brad Nicholson wrote:
> A blog post would be nice, but it seems to me have something about this
> clearly in the manual would be best, assuming it's not there already. I
> took a quick look, and couldn't find anything.
https://www.postgresql.org/docs/devel/sql-copy.html
"Note that the command is invoked by the shell, so if you need to pass
any arguments to shell command that come from an untrusted source, you
must be careful to strip or escape any special characters that might
have a special meaning for the shell. For security reasons, it is best
to use a fixed command string, or at least avoid passing any user input
in it."
"Similarly, the command specified with PROGRAM is executed directly by
the server, not by the client application, must be executable by the
PostgreSQL user. COPY naming a file or command is only allowed to
database superusers or users who are granted one of the default roles
pg_read_server_files, pg_write_server_files, or
pg_execute_server_program, since it allows reading or writing any file
or running a program that the server has privileges to access."
Those seem reasonable to me?
Yes, but I think that the use of the phrase "default roles" here is unfortunate. I know it means that the role exists by default, but it is easy to read that to mean they are granted by default. They should probably be called something like 'built-in roles' or 'system roles'.
And even with the understanding that we are referring to existence, not grant status, "default roles" is still not really correct. If it exists by default, that means I can make it not exist by taking action. But these roles cannot be dropped.
We don't have 'default functions' or 'default types' in the user-facing documentation. We shouldn't call these 'default roles'.
Cheers,
Jeff
