From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
Date: Mon, 30 Nov 2020 18:04:34 -0500
Message-ID: <1346014.1606777474@sss.pgh.pa.us> (raw)
In-Reply-To: <CAGRY4nwwEEkNvXM+7ZFseTb5ffYS+DY-d+22QhqRuJVT+BZjHw@mail.gmail.com>
References: <CALDaNm3ZzmFS-=r7oDUzj7y7BgQv+N06Kqyft6C3xZDoKnk_6w@mail.gmail.com>
<1778088.1606026308@sss.pgh.pa.us>
<CAGRY4nwwEEkNvXM+7ZFseTb5ffYS+DY-d+22QhqRuJVT+BZjHw@mail.gmail.com>
Craig Ringer <craig.ringer@enterprisedb.com> writes:
>> I would like to see some discussion of the security implications
>> of such a feature, as well. ("There aren't any" is the wrong
>> answer.)
> If the stack only goes to the log, I actually don't think there are
> significant security implications beyond those we already have with
> our existing backtrace printing features. We already trust anyone who
> can read the log almost completely, and we can already emit stacks to
> the log. But I'd still want it to be gated superuser-only, or a role
> that's GRANTable by superuser only by default, since it exposes
> arbitrary internals of the server.
The concerns that I had were that the patch as submitted provides a
mechanism that causes ALL processes in the system to dump backtraces,
not a targeted request; and that it allows any user to issue such
requests at an unbounded rate. That seems like a really easy route
to denial of service. There's also a question of whether you'd even
get intelligible results from dozens of processes simultaneously
dumping many-line messages to the same place. (This might work out
all right if you're using our syslogger, but it probably would not
with any other logging technology.)
I'd feel better about it if the mechanism had you specify exactly
one target process, and were restricted to a superuser requestor.
I'm not excited about adding on frammishes like letting one process
extract another's stack trace. I think that just adds more points
of failure, which is a bad thing in a feature that you're only going
to care about when things are a bit pear-shaped already.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig.ringer@enterprisedb.com, vignesh21@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Printing backtrace of postgres processes
In-Reply-To: <1346014.1606777474@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox