On Fri, Apr 5, 2019 at 8:35 AM Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Apr 2, 2019 at 11:31 AM Andres Freund <andres@anarazel.de> wrote:
>> 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
existsby default, but it is easy to read that to mean they are granted by default. They should probably be called
somethinglike '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
reallycorrect. 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
'defaultroles'.
>
As someone who likes to break systems in interesting ways, I do find
it interesting that you can actually remove all superuser roles and/or
the superuser bit from all roles (not that I would recommend that to
anyone) but that these roles cannot be removed without some serious
heavy lifting.
Given that, I think I would tend to agree, describing them more
consistently as "system roles" is probably warranted.
Robert Treat
https://xzilla.net
https://credativ.com
