On Wed, Feb 3, 2021 at 2:30 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I agree. Vignesh points out downthread that it's just printing out memory addresses and not necessarily anything too directly usable, but the memory addresses themselves are potentially security-sensitive. If that were not a thing, there would not be such a thing as ASLR. > 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. That worries me too, although I have a hard time saying exactly why. If we call an OS-provided function called backtrace() and it does something other than generate a backtrace - e.g. makes the process seg fault, or mucks about with the values of global variables - isn't that just a bug in the OS? Do we have particular reasons to believe that such bugs are common? My own skepticism here is mostly based on how inconsistent debuggers are about being able to tell you anything useful, which makes me think that in a binary compiled with any optimization, the ability of backtrace() to do something consistently useful is also questionable. But that's a separate question from whether it's likely to cause any active harm. > 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 agree that ordinary users shouldn't be able to trigger it, but I think it should be restricted to some predefined role, new or existing, rather than to superuser. I see no reason not to let individual users decide what risks they want to take. -- Robert Haas EDB: http://www.enterprisedb.com