Re: CVE-2019-9193 about COPY FROM/TO PROGRAM

On Fri, Apr 5, 2019 at 8:35 AM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Tue, Apr 2, 2019 at 11:31 AM Andres Freund <andres(at)anarazel(dot)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 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'.
>

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