"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, Dec 20, 2020 at 11:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we could draw a line between "safe" and "unsafe" environment
>> variables, I'd be willing to consider a patch that allows directly
>> setting only the former. But I don't see how to draw that line.
> Because if you are writing
> SELECT col1, col2, col3 OR SELECT expression AS col1 \gset
> The query author has explicitly stated which variable names they exactly
> want to change/create and nothing the server can do will be able to alter
> those names.
> Or *is* that the problem - the server might decide to send back a column
> named "breakme1" in the first column position even though the user aliased
> the column name as "col1"?
Yeah, exactly. Just because the SQL output *should* have column names
x, y, z doesn't mean it *will*, if the server is malicious. psql isn't
bright enough to understand what column names the query ought to produce,
so it just believes the column names that come back in the query result.
> Would a "\gsetenv (col1, col2, col3, skip, col4)" be acceptable that leaves
> the name locally defined while relying on column position to match?
Hmm, maybe. The key point here is local vs. remote control of which
variables get assigned to, and offhand that seems like it'd fix the
problem.
> How much do we want to handicap a useful feature because someone can use it
> alongside "SELECT *"?
Whether it's "SELECT *" or "SELECT 1 AS X" doesn't really matter here.
The concern is that somebody has hacked the server to send back something
that is *not* what you asked for. For that matter, since the actual
update isn't visible to the user, the attacker could easily make the
server send back all the columns the user expected ... plus some
he didn't. The attackee might not even realize till later that
something fishy happened.
regards, tom lane
