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