Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Printing backtrace of postgres processes
Date
Msg-id 3886673.1612337426@sss.pgh.pa.us
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Responses Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Re: Printing backtrace of postgres processes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
vignesh C <vignesh21@gmail.com> writes:
> On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
>> Are these superuser and permission checks enough from a security
>> standpoint that we don't expose some sensitive information to the
>> user?

> This will just print the backtrace of the current backend. Users
> cannot get password information from this.

Really?

A backtrace normally exposes the text of the current query, for
instance, which could contain very sensitive data (passwords in ALTER
USER, customer credit card numbers in ordinary data, etc etc).  We
don't allow the postmaster log to be seen by any but very privileged
users; it's not sane to think that this data is any less
security-critical than the postmaster log.

This point is entirely separate from the question of whether
triggering stack traces at inopportune moments could cause system
malfunctions, but that question is also not to be ignored.

TBH, I'm leaning to the position that this should be superuser
only.  I do NOT agree with the idea that ordinary users should
be able to trigger it, even against backends theoretically
belonging to their own userid.  (Do I need to point out that
some levels of the call stack might be from security-definer
functions with more privilege than the session's nominal user?)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Typo in tablesync comment
Next
From: Peter Smith
Date:
Subject: Re: Typo in tablesync comment