Date: Wed, 11 Oct 2017 16:28:03 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Don Seiler <don@seiler.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ervin Weber <webervin@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Passwords in clear text in server log
Message-ID: <20171011202803.GO4628@tamriel.snowman.net>
References: 
 <CAHJZqBCxQth34+KhNji4cQzy9WuNMvpWav863fNDkE0njdq02Q@mail.gmail.com>
 <20171011194323.s2alxtl3krdvj7hj@alvherre.pgsql>
 <CAFC4ZFhLKQ49Jnt75COpK+_68v2uYUkZnDFYhbvy190EpHr_0g@mail.gmail.com>
 <23672.1507752070@sss.pgh.pa.us>
 <CAHJZqBBuYaT5YTv_EaiB_b4-HA8y84eahJbfKfmtpGDfVP6RkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="LFJJY3B0PidKW0RU"
Content-Disposition: inline
In-Reply-To: 
 <CAHJZqBBuYaT5YTv_EaiB_b4-HA8y84eahJbfKfmtpGDfVP6RkQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org


--LFJJY3B0PidKW0RU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Don,

* Don Seiler (don@seiler.us) wrote:
> On Wed, Oct 11, 2017 at 3:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> > We have heard many times from people who don't have enough insight, or
> > enough debug support client-side, to know exactly what queries their
> > apps are issuing.  Disabling query logging would be a horrible setback
> > for debuggability of such apps.  How many times have you said "consult
> > the postmaster log to find out what's going on"?
>=20
> Not logging statements that fail to parse isn't the same as disabling que=
ry
> logging. If a statement fails to parse it can't really be considered a
> query in my opinion. When it fails to parse it *should* send a
> loud-and-clear error to whatever client-side application sent it. Granted=
 a
> lazy developer could code their app to swallow all errors, but then I'd s=
ay
> they deserve the headache.

While I enjoy the general sentiment, it's really just overly constrained
when it comes to the development environments out there today.  Quite
often, developers aren't actually hand-crafting SQL queries but instead
letting some framework or what-have-you generate them and the error
being thrown on a parse failure could be difficult to distinguish from a
server closed connection or similar failure at the higher levels.  Yes,
ideally, that would still end up getting into a log file somewhere, but
now you're talking about the app-side log files which are often spread
across hundreds of app servers, or, at best, collected into some massive
logging system that it isn't easy to look through.

All that said, I'd be open to allowing users to decide if they wish to
log parse errors or not and perhaps we can put some caveats around that
to let people know how logging of parse errors could end up putting
things into the logs that they may not wish were there.  Further, we
could then consider doing something more interesting when it comes to
logging of ALTER ROLE statements when passwords are included, perhaps,
since the above considered switch would eliminate the concern about
syntax errors.

I'm not sure how ugly that would end up getting though, so no promises.

Thanks!

Stephen

--LFJJY3B0PidKW0RU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJZ3n7TAAoJEO1sijiDR2RVtG4P/R7DM9c+Ti0vBTusruQGmtDr
vG5LONi6g+yhPt1t71/TeO3YZm+p3ardeyNuYdpz6igEO9/Oi0ZCWf2iK1ONC0sv
FXZI1rsLU6lF0gjFmG3d1OaM4SQTRFJXYXFnAIPiC/nEzNJv9DFANy4chShFBDob
o0lZPNAr2W85eolMZF2+HdHCenAZE0OtaagImzMGAD4NxP6B4k0w3lKiPVPCrST1
WPeQM+sZnGkWiuymjwtbE6cpNCLa1IajK3FhW9UOn6EdT+sKt+8bomH0JS7xVoft
V6Bw9otmltv47uE4TAhiipX/I1c1BVhauecDfvRxdgJLAUoaEDCBV1Zp1IZ9iYOn
2ncNc8Xi4DS+MhBrmhLFylacqgEMHQYEqFP2UVNKvKdhSCcrNYfjSM5qTD+JFaIj
1IlIeYCk2JTHlISQtc9S84pcAaR+Pyif7uDnmT9mJoG11Z6dcxNj36PpgLg5NJr4
eOhB/QgWtxBY71J4QLoovPfpdyoHFQqu7/pmt1sDpeKFbFd+KNxOE14aJnnjeLo+
qOj3FZLXgs5b7yDvkPbMHnbuokFqdFhi16bPJ58utdOJleDWwGIl5S10vKfyJzGq
qE66kScvDiW8bHYssgS07OtFZQTLd2EFlTnUKgaaUh049qB3ZlL157iJ01TwYDaC
YauNS4Bd6WO3juorsIO/
=8x7x
-----END PGP SIGNATURE-----

--LFJJY3B0PidKW0RU--