On Wed, Feb 15, 2023 at 03:40:26PM +0100, Jelte Fennema wrote:
> On Wed, 15 Feb 2023 at 08:11, Michael Paquier wrote:
>> Hmm, I am not sure that adding more examples in the sample files is
>> worth the duplication with the docs.
>
> I think you misunderstood what I meant (because I admittedly
On Wed, 15 Feb 2023 at 08:11, Michael Paquier wrote:
> Hmm, I am not sure that adding more examples in the sample files is
> worth the duplication with the docs.
I think you misunderstood what I meant (because I admittedly didn't
write it down clearly). I meant the docs for pg_ident don't
On Wed, Feb 15, 2023 at 01:05:04PM +0300, Pavel Luzanov wrote:
> On 15.02.2023 10:11, Michael Paquier wrote:
>> Which comes down to blame me for both of them.
>
> My only intention was to make postgres better.I'm sorry you took it that
> way.
You have no need to feel sorry about that. I really
On 15.02.2023 10:11, Michael Paquier wrote:
Which comes down to blame me for both of them.
My only intention was to make postgres better.I'm sorry you took it that
way.
So, please find attached a patch to close the gap the sample files,
for both things, with descriptions of all the field
On Mon, Feb 13, 2023 at 03:13:04PM +0100, Jelte Fennema wrote:
> On Mon, 13 Feb 2023 at 15:06, Pavel Luzanov wrote:
>> Does it make sense to reflect changes to the PG-USERNAME field in the
>> pg_ident.conf.sample file?
>>
>> The same relates to the regexp supportin the DATABASE and USER fieldsof
On Mon, 13 Feb 2023 at 15:06, Pavel Luzanov wrote:
> Does it make sense to reflect changes to the PG-USERNAME field in the
> pg_ident.conf.sample file?
>
> The same relates to the regexp supportin the DATABASE and USER fieldsof
> the pg_hba.conf.sample file(8fea8683).
That definitely makes sense
Hello,
Playing with this patch, I did not see descriptive comments in
pg_ident.conf.
Does it make sense to reflect changes to the PG-USERNAME field in the
pg_ident.conf.sample file?
The same relates to the regexp supportin the DATABASE and USER fieldsof
the pg_hba.conf.sample
On Thu, Jan 19, 2023 at 12:23:16PM +0100, Jelte Fennema wrote:
> should be either:
> 1. a group membership check
> 2. group membership checks
>
> Now it's mixed singular and plural.
Thanks, fixed. And now applied the last patch.
--
Michael
signature.asc
Description: PGP signature
Looks good to me. One tiny typo in a comment that I noticed when going
over the diff:
+* Mark the token as quoted, so it will only be compared literally
+* and not for some special meaning, such as "all" or a group
+* membership checks.
should be either:
1. a
On Wed, Jan 18, 2023 at 10:35:29AM +0100, Jelte Fennema wrote:
> Anything I can do to help with this? Or will you do that yourself?
So, I have done a second lookup, and tweaked a few things:
- Addition of a macro for pg_strcasecmp(), to match with
token_matches().
- Fixed a bit the documentation.
On Wed, Jan 18, 2023 at 10:35:29AM +0100, Jelte Fennema wrote:
> Anything I can do to help with this? Or will you do that yourself?
Nope. I just need some time to finish wrapping it, that's all.
--
Michael
signature.asc
Description: PGP signature
> 0004 looks fine as well, be it for the tests (I am hesitating to tweak
> things a bit here actually for the role names), the code or the docs,
Anything I can do to help with this? Or will you do that yourself?
On Mon, Jan 16, 2023 at 11:53:57AM +0100, Jelte Fennema wrote:
>> Perhaps it would be simpler to use copy_auth_token() in this code path
>> and always free the resulting token?
>
> I initially tried that when working on the patch, but copy_auth_token
> (surprisingly) doesn't copy the regex field
> Still, I am having a few second thoughts about 0003 after thinking
> about it over the weekend. Except if I am missing something, there
> are no issues with 0004 if we keep the current behavior of always
> replacing \1 even if pg-user is quoted? I would certainly add a new
> test case either
On Fri, Jan 13, 2023 at 09:19:10AM +0100, Jelte Fennema wrote:
>> Even if folks applying quotes
>> would not be able anymore to replace the pattern, the risk seems a bit
>> remote?
>
> Yeah I agree the risk is remote. To be clear, the main pattern I'm
> worried about breaking is simply "\1".
> Even if folks applying quotes
> would not be able anymore to replace the pattern, the risk seems a bit
> remote?
Yeah I agree the risk is remote. To be clear, the main pattern I'm
worried about breaking is simply "\1". Where people had put
quotes around \1 for no reason. All in all, I'm fine if
On Thu, Jan 12, 2023 at 10:10:02AM +0100, Jelte Fennema wrote:
> It also makes the code simpler as we can simply reuse the
> check_role function, since that. I removed the lines you quoted
> since those are actually not strictly necessary. They only change
> the detection logic a bit in case of a
> Simpler is better when it comes to authentication
I definitely agree with that, and if we didn't have existing
parsing logic for pg_hba.conf I would agree. But given the existing
logic for pg_hba.conf, I think the path of least surprises is to
support all of the same patterns that pg_hbac.conf
On Wed, Jan 11, 2023 at 03:22:35PM +0100, Jelte Fennema wrote:
> The main uncertainty I have is if the case insensitivity check is
> actually needed in check_role. It seems like a case insensitive
> check against the database user shouldn't actually be necessary.
> I only understand the need for
> couldn't we also use a regexp for the pg-role rather than
> just a hardcoded keyword here then, so as it would be possible to
> allow a mapping to pass for a group of role names? "all" is just a
> pattern to allow everything, at the end.
That's a good point. I hadn't realised that you added
On Wed, Jan 11, 2023 at 09:04:56AM +, Jelte Fennema wrote:
> It's very different. I think easiest is to explain by example:
>
> If there exist three users on the postgres server: admin, jelte and michael
>
> Then this rule (your suggested rule):
> mapname /^(.*)$ \1
>
> Is equivalent to:
>
> The confusion that 0001 is addressing is fair (cough, fc579e1, cough),
> still I am wondering whether we could do a bit better to be more
Yeah, even after 0001 it's definitely suboptimal. I tried to keep the changes
minimal to not distract from the main purpose of this patch. But I'll update
22 matches
Mail list logo
