David Fetter <da...@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