David Fetter <david@fetter.org> writes:
> On Sun, Dec 20, 2020 at 02:26:14PM +0100, Fabien COELHO wrote:
>> SELECT 'Calvin' AS foo \gset
>> \setenv FOO :foo
>> \! echo $FOO
>> Calvin
> You're the second person who's mentioned this workaround, which goes
> to a couple of points I tried to make earlier:
> - This is not by any means a new capability, just a convenience, and
> - In view of the fact that it's a very old capability, the idea that
> it has implications for controlling access or other parts of the
> space of threat models is pretty silly.
This is essentially the same workaround as what we recommend for anyone
who's unhappy with the fix for CVE-2020-25696: do \gset into a non-special
variable and then copy to the special variable. The reason it seems okay
is that now it is clear that client-side logic intends the special
variable change to happen. Thus a compromised server cannot hijack your
client-side session all by itself. There's nonzero risk in letting the
server modify your PROMPT1, PATH, or whatever, but you took the risk
intentionally (and, presumably, it's necessary to your purposes).
I tend to agree with you that the compromised-server argument is a little
bit of a stretch. Still, we did have an actual user complaining about
the case for \gset, and it's clear that in at least some scenarios this
sort of attack could be used to parlay a server compromise into additional
access. So we're not likely to undo the CVE-2020-25696 fix, and we're
equally unlikely to provide an unrestricted way to set environment
variables directly from the server.
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.
Most of the point of any such feature would have to be to affect
the behavior of shell commands subsequently invoked with \! ...
and we can't know what a given variable would do to those. So on
the whole I'm inclined to leave things as-is, where people have to
do the assignment manually.
regards, tom lane