On Fri, 10 Jan 2020 at 06:16, Andrew Dunstan <andrew.duns...@2ndquadrant.com> wrote:
> On Fri, Jan 10, 2020 at 8:32 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > > > On Fri, Jan 10, 2020 at 1:21 AM Robert Haas <robertmh...@gmail.com> > wrote: > > >> I share the concern about the security issue here. I can't testify to > > >> whether Christoph's whole analysis is here, but as a general point, > > >> non-superusers can't be allowed to do things that cause the server to > > >> access arbitrary local files. > > > > > It's probably fairly easy to do (c.f. 6136e94dcb). I'm not (yet) > > > convinced that there is any significant security threat here. This > > > doesn't give the user or indeed any postgres code any access to the > > > contents of these files. But if there is a consensus to restrict this > > > I'll do it. > > > > Well, even without access to the file contents, the mere ability to > > probe the existence of a file is something we don't want unprivileged > > users to have. And (I suppose) this is enough for that, by looking > > at what error you get back from trying it. > > > > > OK, that's convincing enough. Will do it before long. Thanks. I'm 100% convinced the superuser restriction should be imposed. I can imagine there being a risk of leaking file contents in error output such as parse errors from OpenSSL that we pass on for example. Tricking Pg into reading from a fifo could be problematic too. I should've applied that restriction from the start, the same way as passwordless connections are restricted. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
