On Fri, Sep 24, 2021 at 05:37:48PM -0400, Andrew Dunstan wrote:
> It probably wouldn't be a bad thing to have something somewhere
> (src/test/perl/README ?) that explains when and why we need to bump
> $Test::Builder::Level.
I have some ideas about that. So I propose to move the discussion to
a
On 9/23/21 5:20 PM, Peter Eisentraut wrote:
> On 23.09.21 12:34, Michael Paquier wrote:
>> On Wed, Sep 22, 2021 at 03:18:43PM +, Jacob Champion wrote:
>>> On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
This should be added to each level of a function call that
On 23.09.21 12:34, Michael Paquier wrote:
On Wed, Sep 22, 2021 at 03:18:43PM +, Jacob Champion wrote:
On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
This should be added to each level of a function call that represents a
test. This ensures that when a test fails, the line
On Wed, Sep 22, 2021 at 03:18:43PM +, Jacob Champion wrote:
> On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
>> This should be added to each level of a function call that represents a
>> test. This ensures that when a test fails, the line number points to
>> the top-level
On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
> This should be added to each level of a function call that represents a
> test. This ensures that when a test fails, the line number points to
> the top-level location of the test_role() call. Otherwise it would
> point to the
On 22.09.21 09:39, Michael Paquier wrote:
On Wed, Sep 22, 2021 at 08:59:38AM +0200, Peter Eisentraut wrote:
I noticed this patch eliminated one $Test::Builder::Level assignment. Was
there a reason for this?
I think we should add it back, and also add a few missing ones in similar
places. See
On Wed, Sep 22, 2021 at 08:59:38AM +0200, Peter Eisentraut wrote:
> I noticed this patch eliminated one $Test::Builder::Level assignment. Was
> there a reason for this?
>
> I think we should add it back, and also add a few missing ones in similar
> places. See attached patch.
>
> [...]
>
> {
>
On 03.04.21 14:30, Michael Paquier wrote:
On Fri, Apr 02, 2021 at 01:45:31PM +0900, Michael Paquier wrote:
As a whole, this is a consolidation of its own, so let's apply this
part first.
Slight rebase for this one to take care of the updates with the SSL
error messages.
I noticed this patch
On Tue, Apr 13, 2021 at 03:47:21PM +, Jacob Champion wrote:
> Looks like the farm has gone green, after some test fixups. Thanks for
> all the reviews!
You may want to follow this thread as well, as the topic is related to
what has been discussed on this thread as there is an impact in a
On Wed, 2021-04-07 at 10:20 +0900, Michael Paquier wrote:
> Anyway, using a FATAL in this code path is fine by me at the end, so I
> have applied the patch. Let's see now what the buildfarm thinks about
> it.
Looks like the farm has gone green, after some test fixups. Thanks for
all the reviews!
On Tue, Apr 06, 2021 at 06:31:16PM +, Jacob Champion wrote:
> On Tue, 2021-04-06 at 14:15 +0900, Michael Paquier wrote:
> > Hmm. You are making a good point here, but is that really the best
> > thing we can do? We lose the context of the authentication type being
> > done with this
On Tue, 2021-04-06 at 14:15 +0900, Michael Paquier wrote:
> On Mon, Apr 05, 2021 at 04:40:41PM +, Jacob Champion wrote:
> > This loses the test fixes I made in my v19 [1]; some of the tests on
> > HEAD aren't testing anything anymore. I've put those fixups into 0001,
> > attached.
>
> Argh,
On Mon, Apr 05, 2021 at 04:40:41PM +, Jacob Champion wrote:
> This loses the test fixes I made in my v19 [1]; some of the tests on
> HEAD aren't testing anything anymore. I've put those fixups into 0001,
> attached.
Argh, Thanks. The part about not checking after the error output when
the
On Mon, 2021-04-05 at 14:47 +0900, Michael Paquier wrote:
> On Sat, Apr 03, 2021 at 09:30:25PM +0900, Michael Paquier wrote:
> > Slight rebase for this one to take care of the updates with the SSL
> > error messages.
>
> I have been looking again at that and applied it as c50624cd after
> some
On Sat, Apr 03, 2021 at 09:30:25PM +0900, Michael Paquier wrote:
> Slight rebase for this one to take care of the updates with the SSL
> error messages.
I have been looking again at that and applied it as c50624cd after
some slight modifications. Attached is the main, refactored, patch
that
On Fri, Apr 02, 2021 at 01:45:31PM +0900, Michael Paquier wrote:
> As a whole, this is a consolidation of its own, so let's apply this
> part first.
Slight rebase for this one to take care of the updates with the SSL
error messages.
--
Michael
From 01e836535119dcd5a69ce54e1c86ae51bfba492c Mon Sep
On Fri, 2021-04-02 at 13:45 +0900, Michael Paquier wrote:
> Attached is what I have come up with as the first building piece,
> which is basically a combination of 0001 and 0002, except that I
> modified things so as the number of arguments remains minimal for all
> the routines. This avoids the
On Fri, Apr 02, 2021 at 12:03:21AM +, Jacob Champion wrote:
> On Thu, 2021-04-01 at 10:21 +0900, Michael Paquier wrote:
> > This stuff can take advantage of 0d1a3343, and I
> > think that we should make the kerberos, ldap, authentication and SSL
> > test suites just use connect_ok() and
On Thu, 2021-04-01 at 10:21 +0900, Michael Paquier wrote:
> This stuff can take advantage of 0d1a3343, and I
> think that we should make the kerberos, ldap, authentication and SSL
> test suites just use connect_ok() and connect_fails() from
> PostgresNode.pm. They just need to be extended a bit
On Wed, Mar 31, 2021 at 04:42:32PM +0900, Michael Paquier wrote:
> Attached is an updated patch, with a couple of comments tweaks, the
> reworked tests and an indentation done.
Jacob has mentioned me that v15 has some false positives in the SSL
tests, as we may catch in the backend logs patterns
On Tue, Mar 30, 2021 at 11:15:48PM +, Jacob Champion wrote:
> Rather than putting Postgres log data into the Perl logs, I rotate the
> logs exactly once at the beginning -- so that there's an
> old 001_ssltests_primary.log, and a new 001_ssltests_primary_1.log --
> and then every time we
On Tue, Mar 30, 2021 at 05:06:51PM +, Jacob Champion wrote:
> The key there is "if there is a failure" -- false positives need to be
> debugged too. Tests I've worked with recently for the NSS work were
> succeeding for the wrong reasons. Overly generic logfile matches ("SSL
> error"), for
On Tue, 2021-03-30 at 17:06 +, Jacob Champion wrote:
> Would it be acceptable to adjust the tests for live rotation using the
> logging collector, rather than a full restart? It would unfortunately
> mean that we have to somehow wait for the rotation to complete, since
> that's asynchronous.
On Tue, 2021-03-30 at 09:55 +0900, Michael Paquier wrote:
> On Mon, Mar 29, 2021 at 11:53:03PM +, Jacob Champion wrote:
> > It's not a matter of the tests being stable, but of the tests needing
> > to change and evolve as the implementation changes. A big part of that
> > is visibility into
On Mon, Mar 29, 2021 at 11:53:03PM +, Jacob Champion wrote:
> It's not a matter of the tests being stable, but of the tests needing
> to change and evolve as the implementation changes. A big part of that
> is visibility into what the tests are doing, so that you can debug
> them.
Sure, but I
On Mon, 2021-03-29 at 16:50 +0900, Michael Paquier wrote:
> On Fri, Mar 26, 2021 at 10:41:03PM +, Jacob Champion wrote:
> > For a few of the bugs I was tracking down, it was imperative. The tests
> > aren't isolated enough (or at all) to keep one from affecting the
> > others.
>
> If the
On Fri, Mar 26, 2021 at 10:41:03PM +, Jacob Champion wrote:
> For a few of the bugs I was tracking down, it was imperative. The tests
> aren't isolated enough (or at all) to keep one from affecting the
> others.
If the output of the log file is redirected to stderr and truncated,
while the
On Fri, 2021-03-26 at 09:12 +0900, Michael Paquier wrote:
> Does it really matter to have the full contents of the file from the
> previous tests though?
For a few of the bugs I was tracking down, it was imperative. The tests
aren't isolated enough (or at all) to keep one from affecting the
On Thu, Mar 25, 2021 at 06:51:22PM +, Jacob Champion wrote:
> On Thu, 2021-03-25 at 14:41 +0900, Michael Paquier wrote:
>> + port->authn_id = MemoryContextStrdup(TopMemoryContext, id);
>> It may not be obvious that all the field is copied to TopMemoryContext
>> because the Port requires
On Thu, 2021-03-25 at 14:41 +0900, Michael Paquier wrote:
> I got to look at the DN patch yesterday, so now's the turn of this
> one. Nice work.
Thanks!
> + port->authn_id = MemoryContextStrdup(TopMemoryContext, id);
> It may not be obvious that all the field is copied to TopMemoryContext
>
On Wed, Mar 24, 2021 at 04:45:35PM +, Jacob Champion wrote:
> With low-coverage test suites, I think it's useful to allow as little
> strange behavior as possible -- in this case, printing authorization
> before authentication could signal a serious bug -- but I don't feel
> too strongly about
On Tue, 2021-03-23 at 14:21 +0900, Michael Paquier wrote:
> I am not really sure that we need to bother about the ordering of the
> entries here, as long as we check for all of them within the same
> fragment of the log file, so I would just go down to the simplest
> solution that I posted
On Mon, Mar 22, 2021 at 06:22:52PM +0100, Magnus Hagander wrote:
> The 0002/0001/whateveritisaftertherebase is tracked over at
> https://www.postgresql.org/message-id/flat/92e70110-9273-d93c-5913-0bccb6562...@dunslane.net
> isn't it? I've assumed the expectation is to have that one committed
>
On Mon, Mar 22, 2021 at 07:17:26PM +, Jacob Champion wrote:
> v8's test_access lost the in-order log search from v7; I've added it
> back in v9. The increased resistance to entropy seems worth the few
> extra lines. Thoughts?
I am not really sure that we need to bother about the ordering of
On Mon, 2021-03-22 at 15:16 +0900, Michael Paquier wrote:
> On Fri, Mar 19, 2021 at 06:37:05PM +, Jacob Champion wrote:
> > The same effect can be had by moving the log rotation to the top of the
> > test that needs it, so I've done it that way in v7.
>
> After thinking more about 0001, I
On Mon, 2021-03-22 at 18:22 +0100, Magnus Hagander wrote:
> On Mon, Mar 22, 2021 at 7:16 AM Michael Paquier wrote:
> >
> > I have briefly looked at 0002 (0001 in the attached set), and it seems
> > sane to me. I still need to look at 0003 (well, now 0002) in details,
> > which is very sensible
On Mon, Mar 22, 2021 at 7:16 AM Michael Paquier wrote:
>
> On Fri, Mar 19, 2021 at 06:37:05PM +, Jacob Champion wrote:
> > The same effect can be had by moving the log rotation to the top of the
> > test that needs it, so I've done it that way in v7.
>
> After thinking more about 0001, I have
On Fri, Mar 19, 2021 at 06:37:05PM +, Jacob Champion wrote:
> The same effect can be had by moving the log rotation to the top of the
> test that needs it, so I've done it that way in v7.
After thinking more about 0001, I have come up with an even simpler
solution that has resulted in
On Fri, 2021-03-19 at 16:54 +, Jacob Champion wrote:
> One additional improvement I would suggest, now that the rotation logic
> is simpler than it was in my original patch, is to rotate the logfile
> regardless of whether the test is checking the logs or not. (Similarly,
> we can manually
On Fri, 2021-03-19 at 17:21 +0900, Michael Paquier wrote:
> On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote:
> > Looking at 0001, I am not much a fan of relying on the position of the
> > matching pattern in the log file. Instead of relying on the logging
> > collector and one
On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote:
> Looking at 0001, I am not much a fan of relying on the position of the
> matching pattern in the log file. Instead of relying on the logging
> collector and one single file, why not just changing the generation of
> the logfile
On Mon, Mar 15, 2021 at 03:50:48PM +, Jacob Champion wrote:
> # might need to retry if logging collector process is slow...
> my $max_attempts = 180 * 10;
> my $first_logfile;
> for (my $attempts = 0; $attempts < $max_attempts;
On Tue, 2021-03-09 at 19:10 +, Jacob Champion wrote:
> And v5 is rebased over this morning's SSL test changes.
Rebased again after the SSL test revert (this is the same as v4).
--Jacob
From 470bf11f4b8feb6c22dc72626f6f3fcb7971ac26 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Wed, 3
On Tue, 2021-03-09 at 18:03 +, Jacob Champion wrote:
> v4 removes the TODO and the extra allocation for peer_user. I'll hold
> off on the other two suggestions pending that conversation.
And v5 is rebased over this morning's SSL test changes.
--Jacob
From
On Mon, 2021-03-08 at 22:16 +, Jacob Champion wrote:
> On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> > As for log escaping, we report port->user_name already unescaped --
> > surely this shouldn't be a worse case than that?
>
> Ah, that's a fair point. I'll remove the TODO.
v4
On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> In fact, if we're storing it in the Port, why
> are we even passing it as a separate parameter to check_usermap --
> shouldn't that one always use this same value?
Ah, and now I remember why I didn't consolidate this to begin with.
On Mon, 2021-03-08 at 22:16 +, Jacob Champion wrote:
> On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> > With this we store the same value as the authn and as
> > port->gss->princ, and AFAICT it's only used once. Seems we could just
> > use the new field for the gssapi usage as
On Sat, 2021-03-06 at 18:33 +0100, Magnus Hagander wrote:
> It looks like patch 0001 has some leftover debuggnig code at the end?
> Or did you intend for that to be included permanently?
I'd intended to keep it -- it works hand-in-hand with the existing
"current_logfiles" log line on 219 and
On Fri, Feb 26, 2021 at 8:45 PM Jacob Champion wrote:
>
> On Thu, 2021-02-11 at 20:32 +, Jacob Champion wrote:
> > v2 just updates the patchset to remove the Windows TODO and fill in the
> > patch notes; no functional changes. The question about escaping log
> > contents remains.
>
> v3
On Thu, 2021-02-11 at 20:32 +, Jacob Champion wrote:
> v2 just updates the patchset to remove the Windows TODO and fill in the
> patch notes; no functional changes. The question about escaping log
> contents remains.
v3 rebases onto latest master, for SSL test conflicts.
Note:
- Since the
On Mon, 2021-02-08 at 23:35 +, Jacob Champion wrote:
> Note that I haven't compiled or tested on
> Windows and BSD yet, so the SSPI and BSD auth changes are eyeballed for
> now.
I've now tested on both.
> - For the SSPI auth method, I pick the format of the identity string
> based on the
On Tue, 2021-02-02 at 22:22 +, Jacob Champion wrote:
> Given the feedback above, I'll continue to flesh out the PoC patch,
> focusing on 1) storing the identity in a single place for all auth
> methods and 2) exposing it consistently in the logs as part of
> log_connections.
Attached is a v1
On Thu, 2021-01-28 at 18:22 +, Jacob Champion wrote:
> = Proposal =
>
> 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
On Mon, 2021-02-01 at 18:40 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > My goal is to get this one single point of reference, for all of the
> > auth backends. The LDAP mapping conversation is separate.
>
> Presumably this would be the DN for SSL then..? Not
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Mon, 2021-02-01 at 18:01 -0500, Stephen Frost wrote:
> > Ok.. but what's 'go' mean here? We already have views and such for GSS
> > and SSL, is the idea to add another view for LDAP and add in columns
> > that are returned by
On Mon, 2021-02-01 at 18:01 -0500, Stephen Frost wrote:
> Ok.. but what's 'go' mean here? We already have views and such for GSS
> and SSL, is the idea to add another view for LDAP and add in columns
> that are returned by pg_stat_get_activity() which are then pulled out by
> that view? Or did
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Mon, 2021-02-01 at 17:01 -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > > And I'm not holding
> > > my breath for LDAP servers to start implementing federated identity,
> > > though that would be
On Mon, 2021-02-01 at 17:01 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > And I'm not holding
> > my breath for LDAP servers to start implementing federated identity,
> > though that would be nice.
>
> Not sure exactly what you're referring to here but AD
On Mon, 2021-02-01 at 18:44 +0100, Magnus Hagander wrote:
> What people would *really* want I think is "alow auto-creation of new
> roles, and then look up which other roles they should be members of
> using ldap" (or "using this script over here" for a more flexible
> approach). Which is of
On Mon, Feb 1, 2021 at 10:36 PM Jacob Champion wrote:
>
> On Sun, 2021-01-31 at 12:27 +0100, Magnus Hagander wrote:
> > > (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.)
> >
> >
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Mon, 2021-02-01 at 11:49 -0500, Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > But yes, I think the enforced cleartext password proxying is at the
> > > core of the problem. LDAP also encourages the idea
On Mon, 2021-02-01 at 11:49 -0500, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > But yes, I think the enforced cleartext password proxying is at the
> > core of the problem. LDAP also encourages the idea of centralized
> > password-reuse, which is not exactly a great
On Sun, 2021-01-31 at 12:27 +0100, Magnus Hagander wrote:
> > (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.)
>
> Specifically for search+bind, I would assume?
Even for the simple bind
On Mon, Feb 1, 2021 at 6:32 PM Tom Lane wrote:
>
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> This doesn't sound particularly workable: how would you manage
> >> inside-the-database permissions? Kerberos isn't going to know
> >> what "view foo" is, let alone know
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> This doesn't sound particularly workable: how would you manage
> >> inside-the-database permissions? Kerberos isn't going to know
> >> what "view foo" is, let alone know
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> This doesn't sound particularly workable: how would you manage
>> inside-the-database permissions? Kerberos isn't going to know
>> what "view foo" is, let alone know whether you should be allowed
>> to read or write it. So ISTM
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Greg Stark writes:
> > I wonder if there isn't room to handle this the other way around. To
> > configure Postgres to not need a CREATE ROLE for every role but
> > delegate the user management to the external authentication service.
>
> > So
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Sat, Jan 30, 2021 at 12:21 AM Jacob Champion wrote:
> > > 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
Greg Stark writes:
> I wonder if there isn't room to handle this the other way around. To
> configure Postgres to not need a CREATE ROLE for every role but
> delegate the user management to the external authentication service.
> So Postgres would consider the actual role to be the one kerberos
Magnus Hagander writes:
> On Sat, Jan 30, 2021 at 12:40 AM Tom Lane wrote:
>> I remain concerned about the cost and inconvenience of exposing
>> it via log_line_prefix, but at least that shouldn't be visible
>> to anyone who's not entitled to know who's logged in ...
> What if we logged it as
On Fri, 29 Jan 2021 at 18:41, Tom Lane wrote:
>
> Ah. So basically, this comes into play when you consider that some
> outside-the-database entity is your "real" authenticated identity.
> That seems reasonable when using Kerberos or the like, though it's
> not real meaningful for traditional
On Sat, Jan 30, 2021 at 12:21 AM Jacob Champion wrote:
>
> 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
On Sat, Jan 30, 2021 at 12:40 AM Tom Lane wrote:
>
> Jacob Champion writes:
> > On Fri, 2021-01-29 at 17:30 -0500, Tom Lane wrote:
> >> What happens if ALTER USER RENAME is done while the session is still
> >> alive?
>
> > IMO the authenticated identity should be write-once. Especially since
> >
On Fri, 2021-01-29 at 18:40 -0500, Tom Lane wrote:
> Ah. So basically, this comes into play when you consider that some
> outside-the-database entity is your "real" authenticated identity.
> That seems reasonable when using Kerberos or the like, though it's
> not real meaningful for traditional
Jacob Champion writes:
> On Fri, 2021-01-29 at 17:30 -0500, Tom Lane wrote:
>> What happens if ALTER USER RENAME is done while the session is still
>> alive?
> IMO the authenticated identity should be write-once. Especially since
> one of my goals is to have greater auditability into events as
On Fri, 2021-01-29 at 17:30 -0500, Tom Lane wrote:
> What happens if ALTER USER RENAME is done while the session is still
> alive?
IMO the authenticated identity should be write-once. Especially since
one of my goals is to have greater auditability into events as they've
actually happened. So
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
Stephen Frost writes:
> * Jacob Champion (pchamp...@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
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> First, the context: recently I've been digging into the use of third-
> party authentication systems with Postgres. One sticking point is the
> need to have a Postgres role corresponding to the third-party user
> identity, which becomes
Hello all,
First, the context: recently I've been digging into the use of third-
party authentication systems with Postgres. One sticking point is the
need to have a Postgres role corresponding to the third-party user
identity, which becomes less manageable at scale. I've been trying to
come up
80 matches
Mail list logo
