Re: Printing backtrace of postgres processes

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Printing backtrace of postgres processes
Date: 2021-02-03 08:19:27
Message-ID: CALDaNm0aKEpGXf-7RN87B_DXZ8XTnuMGOA5NR6f2b532AhMAyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 3, 2021 at 1:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> vignesh C <vignesh21(at)gmail(dot)com> writes:
> > On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> > <bharath(dot)rupireddyforpostgres(at)gmail(dot)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?)
>

I had seen that the log that will be logged will be something like:
postgres: test postgres [local]
idle(ProcessClientReadInterrupt+0x3a) [0x9500ec]
postgres: test postgres [local] idle(secure_read+0x183) [0x787f43]
postgres: test postgres [local] idle() [0x7919de]
postgres: test postgres [local] idle(pq_getbyte+0x32) [0x791a8e]
postgres: test postgres [local] idle() [0x94fc16]
postgres: test postgres [local] idle() [0x950099]
postgres: test postgres [local] idle(PostgresMain+0x6d5) [0x954bd5]
postgres: test postgres [local] idle() [0x898a09]
postgres: test postgres [local] idle() [0x89838f]
postgres: test postgres [local] idle() [0x894953]
postgres: test postgres [local] idle(PostmasterMain+0x116b) [0x89422a]
postgres: test postgres [local] idle() [0x79725b]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f6e68d75555]
postgres: test postgres [local] idle() [0x484249]
I was not sure if we would be able to get any secure information from
this. I did not notice the function arguments being printed. I felt
the function name, offset and the return address will be logged. I
might be missing something here.
Thoughts?

Regards,
Vignesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message japin 2021-02-03 08:32:10 Re: Support ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ... syntax
Previous Message Michael Paquier 2021-02-03 08:04:59 Re: Typo in tablesync comment