Re: Proposal: Save user's original authenticated identity for logging
От | Jacob Champion |
---|---|
Тема | Re: Proposal: Save user's original authenticated identity for logging |
Дата | |
Msg-id | e5bcc7f6bf9a3bd7751f97e2c34a5b877d3cbe4c.camel@vmware.com обсуждение исходный текст |
Ответ на | Re: Proposal: Save user's original authenticated identity for logging (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Proposal: Save user's original authenticated identity for logging
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: