From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow matching whole DN from a client certificate |
Date: | 2021-01-29 13:18:09 |
Message-ID: | 9EDFE44E-DF64-4C4F-BE89-9710B7908976@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 28 Jan 2021, at 23:10, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 1/28/21 11:39 AM, Jacob Champion wrote:
>>
>> Unfortunately I don't really know what that solution should look like.
>> A DSL for filtering on RDNs would be a lot of work, but it could
>> potentially allow LDAP to be mapped through pg_ident as well
>
> In the end it will be up to users to come up with expressions that meet
> their usage. Yes they could get it wrong, but then they can get so many
> things wrong ;-)
My main concern with this isn't that it's easy to get it wrong, but that it may
end up being hard to get it right (with false positives in the auth path as a
result). Right now I'm not sure where it leans.
Maybe it will be easier to judge the proposal when the documentation has been
updated warnings for the potential pitfalls?
--
Daniel Gustafsson https://vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-01-29 13:40:24 | Re: Printing backtrace of postgres processes |
Previous Message | Peter Eisentraut | 2021-01-29 13:14:48 | Re: Dumping/restoring fails on inherited generated column |