Re: Redacting information from logs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Redacting information from logs
Date: 2019-08-03 23:14:13
Message-ID: 5535.1564874053@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-07-30 11:54:55 -0700, Jeff Davis wrote:
>> My proposal is:
>> * redact every '%s' in an ereport by having a special mode for
>> snprintf.c (this is possible because we now own snprintf)

> I'm extremely doubtful this is a sane approach.

Yeah, it's really hard to believe that messing with snprintf isn't
going to have a lot of unintended consequences. If we want to do
something about this, we're going to have to bite the bullet and
go around to annotate all those arguments with redaction-worthiness
info. It'd be a lot of work, but as long as we can make sure to
do it incrementally, we could get there. (It's not like ereport
itself has been there forever ...)

> I.e. something very roughly like

> ereport(ERROR,
> errmsg_rich("string with %{named}s references to %{parameter}s"),
> errparam("named", somevar),
> errparam("parameter", othervar, .redact = CONTEXT));

I'm not terribly attracted by that specific approach, though. With
this, we'd get to maintain *two* variants of snprintf, and I think
the one with annotation knowledge would have significant performance
problems. (Something I'm sensitive to, on account of certain persons
beating me over the head about snprintf.c's performance.) It'd be
an amazing pain in the rear for translators, too, on account of
their tools not understanding this format-string language.

It seems to me that it'd be sufficient to do the annotation by
inserting wrapper functions, like the errparam() you suggest above.
If we just had errparam() choosing whether to return "..." instead of
its argument string, we'd have what we need, without messing with
the format language.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2019-08-04 00:41:24 Re: pglz performance
Previous Message Chapman Flack 2019-08-03 22:57:44 Re: Redacting information from logs