| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jacob Champion <pchampion(at)vmware(dot)com> |
| Cc: | "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net>, "stark(at)mit(dot)edu" <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Proposal: Save user's original authenticated identity for logging |
| Date: | 2021-03-22 06:16:32 |
| Message-ID: | YFg2QJolwvV7K33B@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 19, 2021 at 06:37:05PM +0000, Jacob Champion wrote:
> The same effect can be had by moving the log rotation to the top of the
> test that needs it, so I've done it that way in v7.
After thinking more about 0001, I have come up with an even simpler
solution that has resulted in 11e1577. That's similar to what
PostgresNode::issues_sql_like() does. This also makes 0003 simpler
with its changes as this requires to change two lines in test_access.
> Turns out it's easy now to have our cake and eat it too; a single if
> statement can implement the same search-forward functionality that was
> spread across multiple places before. So I've done that too.
I have briefly looked at 0002 (0001 in the attached set), and it seems
sane to me. I still need to look at 0003 (well, now 0002) in details,
which is very sensible as one mistake would likely be a CVE-class
bug.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| v8-0001-ssl-store-client-s-DN-in-port-peer_dn.patch | text/x-diff | 3.2 KB |
| v8-0002-Log-authenticated-identity-from-all-auth-backends.patch | text/x-diff | 27.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neha Sharma | 2021-03-22 06:23:13 | [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb |
| Previous Message | torikoshia | 2021-03-22 06:09:58 | Re: Get memory contexts of an arbitrary backend process |