From: Jacob Champion <pchampion@vmware.com>
To: sfrost@snowman.net <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Proposal: Save user's original authenticated identity for logging
Date: Fri, 29 Jan 2021 23:21:36 +0000
Message-ID: <e5bcc7f6bf9a3bd7751f97e2c34a5b877d3cbe4c.camel@vmware.com> (raw)
In-Reply-To: <20210129220101.GE27507@tamriel.snowman.net>
References: <c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com>
<20210129220101.GE27507@tamriel.snowman.net>
On Fri, 2021-01-29 at 17:01 -0500, Stephen Frost wrote:
> > - for LDAP, the bind DN is discarded entirely;
>
> We don't support pg_ident.conf-style entries for LDAP, meaning that the
> user provided has to match what we check, so I'm not sure what would be
> improved with this change..?
For simple binds, this gives you almost nothing. For bind+search,
logging the actual bind DN is still important, in my opinion, since the
mechanism for determining it is more opaque (and may change over time).
But as Tom noted -- for both cases, if the role name changes, this
mechanism can still help you audit who the user _actually_ bound as,
not who you think they should have bound as based on their current role
name.
(There's also the fact that I think pg_ident mapping for LDAP would be
just as useful as it is for GSS or certs. That's for a different
conversation.)
> I'm also just generally not thrilled with
> putting much effort into LDAP as it's a demonstrably insecure
> authentication mechanism.
Because Postgres has to proxy the password? Or is there something else?
> > 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.
Agreed in principle... Is the CSV format configurable? Forcing it into
CSV logs by default seems like it'd be a hard sell, especially for
people not using pg_ident.
> For some auth methods, eg: GSS, we've recently added information into
> the authentication method which logs what the authenticated identity
> was. The advantage with that approach is that it avoids bloating the
> log by only logging that information once upon connection rather than
> 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.
As long as the identity can be easily logged and reviewed by DBAs, I'm
happy.
--Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, sfrost@snowman.net
Subject: Re: Proposal: Save user's original authenticated identity for logging
In-Reply-To: <e5bcc7f6bf9a3bd7751f97e2c34a5b877d3cbe4c.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox