Re: Proposal: Save user's original authenticated identity for logging

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

In response to

Browse pgsql-hackers by date

  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