From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Jacob Champion <pchampion@vmware.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Proposal: Save user's original authenticated identity for logging
In-reply-to: <20210129220101.GE27507@tamriel.snowman.net>
References: <c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com>
 <20210129220101.GE27507@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Fri, 29 Jan 2021 17:01:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2829029.1611959442.1@sss.pgh.pa.us>
Date: Fri, 29 Jan 2021 17:30:42 -0500
Message-ID: <2829030.1611959442@sss.pgh.pa.us>
Precedence: bulk

Stephen Frost <sfrost@snowman.net> writes:
> * Jacob Champion (pchampion@vmware.com) wrote:
>> I propose that every auth method should store the string it uses to
>> identify a user -- what I'll call an "authenticated identity" -- into
>> one central location in Port, after authentication succeeds but before
>> any pg_ident authorization occurs. This field can then be exposed in
>> log_line_prefix. (It could additionally be exposed through a catalog
>> table or SQL function, if that were deemed useful.) This would let a
>> DBA more easily audit user activity when using more complicated
>> pg_ident setups.

> This seems like it would be good to include the CSV format log files
> also.

What happens if ALTER USER RENAME is done while the session is still
alive?

More generally, exposing this in log_line_prefix seems like an awfully
narrow-minded view of what people will want it for.  I'd personally
think pg_stat_activity a better place to look, for example.

> on every log line...  I wonder if we should be focusing on a similar
> approach for other pg_ident.conf use-cases instead of having it via
> log_line_prefix, as the latter means we'd be logging the same value over
> and over again on every log line.

Yeah, this seems like about the most expensive way that we could possibly
choose to make the info available.

			regards, tom lane