From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net> |
Cc: | "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-09 00:48:20 |
Message-ID: | 36ad4829f46a30b16355b60d45f43f89b89dac52.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> In fact, if we're storing it in the Port, why
> are we even passing it as a separate parameter to check_usermap --
> shouldn't that one always use this same value?
Ah, and now I remember why I didn't consolidate this to begin with.
Several auth methods perform some sort of translation before checking
the usermap: cert pulls the CN out of the Subject DN, SSPI and GSS can
optionally strip the realm, etc.
> ISTM that it could be
> quite confusing if the logged value is different from whatever we
> apply to the user mapping?
Maybe. But it's an accurate reflection of what's actually happening,
and that's the goal of the patch: show enough information to be able to
audit who's logging in. The certificates
/OU=ACME Ltd./C=US/CN=pchampion
and
/OU=Postgres/C=GR/CN=pchampion
are different identities, but Postgres will silently authorize them to
log in as the same user. In my opinion, hiding that information makes
things more confusing in the long term, not less.
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-03-09 00:57:31 | Re: Boundary value check in lazy_tid_reaped() |
Previous Message | Michael Paquier | 2021-03-09 00:47:11 | Re: Let people set host(no)ssl settings from initdb |