Re: \gsetenv

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: \gsetenv
Дата
Msg-id 23716.1608157813@sss.pgh.pa.us
обсуждение исходный текст
Ответ на \gsetenv  (David Fetter <david@fetter.org>)
Ответы Re: \gsetenv  (David Fetter <david@fetter.org>)
Список pgsql-hackers
David Fetter <david@fetter.org> writes:
> We have \gset to set some parameters, but not ones in the environment,
> so I fixed this with a new analogous command, \gsetenv.

In view of the security complaints we just had about \gset
(CVE-2020-25696), I cannot fathom why we'd consider adding another
way to cause similar problems.

We were fortunate enough to be able to close off the main security risk
of \gset without deleting the feature altogether ... but how exactly
would we distinguish "safe" from "unsafe" environment variables?  It kind
of seems like anything that would be worth setting at all would tend to
fall into the "unsafe" category, because the implications of setting it
would be unclear.  But *for certain* we're not taking a patch that allows
remotely setting PATH and things like that.

Besides which, you haven't bothered with even one word of positive
justification.  What's the non-hazardous use case?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Add docs stub for recovery.conf
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: A few new options for CHECKPOINT