Steven Siebert <smsiebe@gmail.com> writes:
> Attached is the patch (against master) for the approach we discussed:
> sanitizing the log message by removing the sensitive information out of the
> hba raw line.
I still say that this is an ill-considered, unmaintainable, and
fundamentally insecure approach to solving the wrong problem.
As a single example of what's wrong with it, suppose that you
fat-finger some syntax detail of an LDAP line in pg_hba.conf.
When you issue "pg_ctl reload", will the postmaster log the broken
line in the postmaster log? I sure hope so, because not doing so
would be a major usability fail. Will it obscure the RADIUS secret?
No, because the syntax error will prevent it from correctly
identifying which part of the line is the secret, if indeed it
even realizes that the line might contain a secret.
If we go down this path, we'll be battling "oh, but what about that
other scenario?" cases till kingdom come; there will never be any
reason to think we've covered them all.
The right problem to be solving, to my mind, is that you feel a need
to give access to the postmaster log to untrusted people. Now maybe
that's just a problem of wrong administrative procedures, but let's
consider what we might do in PG to improve your ability to do that
safely. Perhaps what we should be entertaining is a proposal to have
multiple log channels, some containing more security-relevant messages
and others less so. Then you could give people the ability to read only
the non-security-relevant messages. If we arranged for *all* messages
relevant to pg_hba.conf to go into a secure log, it'd be a lot easier to
convince ourselves that we would not leak any security-critical info
than if we take the approach this patch proposes.
regards, tom lane