Re: Adding support for SSLKEYLOGFILE in the frontend
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Abhishek Chanda <abhishek.becs@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2025-01-09T01:17:30Z
Lists: pgsql-hackers
Abhishek Chanda <abhishek.becs@gmail.com> writes: > Attached is a patch to add support for logging secrets used in TLS > connection after psql is initialized. This adds a new env var > SSLKEYLOGFILE on the client side that points to a text file where keys > will be logged. I wonder if this poses a security risk, ie something forcing extraction of TLS secrets at a distance via the environment variable. I think it might be safer if we only accepted it as a connection parameter and not via an environment variable. (I'm aware of the rule of thumb that if you control the environment then you own your callees anyway, via modifying PATH and suchlike. But there's a lot of code that thinks it can sanitize the environment by overriding PATH and other well-known variables. Nobody is going to be aware that SSLKEYLOGFILE is a security hazard.) > 2. Should I use perror to report error here? No. > I did not want to use > libpq_append_conn_error because this is not a connection related > error. Yes it is, IMO anyway. Anything like this should be treated as a libpq connection parameter. The reason you couldn't find a place to document this feature is you were ignoring libpq's conventions. Just looking at the code itself, I'm a bit distressed that it's not making any effort to secure the log file against prying eyes. Shouldn't we be trying to create it with mode 0600? regards, tom lane
Commits
-
Fix sslkeylogfile error handling logging
- a6c0bf93031d 19 (unreleased) landed
- 39f01083facd 18.0 landed
-
Mark sslkeylogfile as Debug option
- 2970c75dd982 18.0 landed
-
libpq: Add support for dumping SSL key material to file
- 2da74d8d6400 18.0 landed