On 2019-07-24 22:18, Tom Lane wrote:
>> I think we could just define that if geteuid == getpeereid, then
>> authentication succeeds. Possibly make that a setting if someone wants
>> to turn it off.
>
> We would still need to make the proposed buildfarm changes, though,
> because Windows. (And
Peter Eisentraut writes:
> If I'm logged in as the OS user that owns the data directory, I should
> be able to log in to the database system via local socket as any user.
> Because why stop me? I can just change pg_hba.conf to let me in.
Hmm ... there's probably some minor loss of safety there,
On 2019-07-22 19:40, Andres Freund wrote:
> On 2019-07-22 13:02:13 -0400, Andrew Dunstan wrote:
>> There are a few things we could do. We could force trust auth, or we
>> could add an ident map that allowed $USER to login as buildfarm. Finding
>> all the places we would need to fix that could be a
On 7/24/19 10:00 AM, Andrew Dunstan wrote:
> On 7/23/19 2:12 AM, Peter Eisentraut wrote:
>> On 2019-07-22 21:16, Andrew Dunstan wrote:
>>> Modulo this issue, experimentation shows that adding '-A trust' to the
>>> line in run_build.pl where initdb is called fixes the issue. If we're
>>> going to
On 2019-07-24 16:00, Andrew Dunstan wrote:
> I think we also need to change vcregress.pl to use trust explicitly for
> upgrade checks, just like the Unix upgrade test script does. That should
> help to future-proof us a bit.
Right, I'll add that to my patch.
--
Peter Eisentraut
On 7/23/19 2:12 AM, Peter Eisentraut wrote:
> On 2019-07-22 21:16, Andrew Dunstan wrote:
>> Modulo this issue, experimentation shows that adding '-A trust' to the
>> line in run_build.pl where initdb is called fixes the issue. If we're
>> going to rely on a buildfarm client fix that one seems
On 7/22/19 1:40 PM, Andres Freund wrote:
> Hi,
>
> On 2019-07-22 13:02:13 -0400, Andrew Dunstan wrote:
>> There are a few things we could do. We could force trust auth, or we
>> could add an ident map that allowed $USER to login as buildfarm. Finding
>> all the places we would need to fix that
Hi,
On 2019-07-22 13:02:13 -0400, Andrew Dunstan wrote:
> There are a few things we could do. We could force trust auth, or we
> could add an ident map that allowed $USER to login as buildfarm. Finding
> all the places we would need to fix that could be a fun project ...
Perhaps we could
On 2019-07-22 21:16, Andrew Dunstan wrote:
> Modulo this issue, experimentation shows that adding '-A trust' to the
> line in run_build.pl where initdb is called fixes the issue. If we're
> going to rely on a buildfarm client fix that one seems simplest.
Yes, that is the right fix. It's what the
On 7/22/19 3:20 PM, Andrew Dunstan wrote:
>
> On 7/22/19 3:15 PM, Tom Lane wrote:
>>
>> Frankly, this episode makes me wonder whether changing the default is
>> even a good idea at this point. People who care about security have
>> already set up their processes to select a useful-to-them auth
I wrote:
> I tried doing a run on gaur (old HPUX, so no "peer" auth) before the
> revert happened. It got as far as initdb-check [1], which failed quite
> thoroughly with lots of the same error as above.
> ...
> Presumably Noah's AIX menagerie would have failed in about the
> same way if it had
On 7/22/19 3:15 PM, Tom Lane wrote:
> I wrote:
>> BTW, it looks like the Windows buildfarm critters have a
>> separate problem: they're failing with
>> initdb: error: must specify a password for the superuser to enable md5
>> authentication
> I tried doing a run on gaur (old HPUX, so no "peer"
On 7/22/19 12:39 PM, Tom Lane wrote:
> I wrote:
>> I'm afraid we're going to have to revert this, at least till
>> such time as a fixed buildfarm client is in universal use.
>> As for the nature of that fix, I don't quite understand why
>> the forced -U is there --- maybe we could just remove
I wrote:
> BTW, it looks like the Windows buildfarm critters have a
> separate problem: they're failing with
> initdb: error: must specify a password for the superuser to enable md5
> authentication
I tried doing a run on gaur (old HPUX, so no "peer" auth) before the
revert happened. It got as
On 7/22/19 12:25 PM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> Pushed with that note. Thanks.
>> This has completely broken the buildfarm.
> On inspection, it seems the reason for that is that the buildfarm
> script runs initdb with '-U buildfarm', so that peer-auth
I wrote:
> I'm afraid we're going to have to revert this, at least till
> such time as a fixed buildfarm client is in universal use.
> As for the nature of that fix, I don't quite understand why
> the forced -U is there --- maybe we could just remove it?
> But there are multiple places in the
I wrote:
> Peter Eisentraut writes:
>> Pushed with that note. Thanks.
> This has completely broken the buildfarm.
On inspection, it seems the reason for that is that the buildfarm
script runs initdb with '-U buildfarm', so that peer-auth connections
will only work if the buildfarm is being run
Peter Eisentraut writes:
> Pushed with that note. Thanks.
This has completely broken the buildfarm.
regards, tom lane
On 2019-07-13 18:58, Julien Rouhaud wrote:
>>> The default client authentication setup is such that users can connect
>>> over the Unix-domain socket to the same database user name as their
>>> operating system user names (on operating systems that support this,
>>> which are most modern Unix-like
On Sat, Jul 13, 2019 at 2:44 PM Peter Eisentraut
wrote:
>
> On 2019-07-11 21:34, Julien Rouhaud wrote:
> >> Note that with this change, running initdb without arguments will now
> >> error on those platforms: You need to supply either a password or select
> >> a different default authentication
On 2019-07-11 21:34, Julien Rouhaud wrote:
>> Note that with this change, running initdb without arguments will now
>> error on those platforms: You need to supply either a password or select
>> a different default authentication method.
> Should we make this explicitly stated in the
On Thu, Jul 11, 2019 at 09:34:25PM +0200, Julien Rouhaud wrote:
> On Tue, Jun 18, 2019 at 10:33 PM Peter Eisentraut
> wrote:
> >
> > On 2019-05-23 18:54, Peter Eisentraut wrote:
> > > To recap, the idea here was to change the default authentication methods
> > > that initdb sets up, in place of
On Tue, Jun 18, 2019 at 10:33 PM Peter Eisentraut
wrote:
>
> On 2019-05-23 18:54, Peter Eisentraut wrote:
> > To recap, the idea here was to change the default authentication methods
> > that initdb sets up, in place of "trust".
> >
> > I think the ideal scenario would be to use "peer" for local
On 2019-05-23 18:54, Peter Eisentraut wrote:
> To recap, the idea here was to change the default authentication methods
> that initdb sets up, in place of "trust".
>
> I think the ideal scenario would be to use "peer" for local and some
> appropriate password method (being discussed elsewhere)
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, May 28, 2019 at 12:15:35PM -0400, Magnus Hagander wrote:
> > On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> > > On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > > > On Thu, May 23, 2019, 18:54 Peter Eisentraut
On Tue, May 28, 2019 at 12:15:35PM -0400, Magnus Hagander wrote:
> On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> > On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > > On Thu, May 23, 2019, 18:54 Peter Eisentraut
> > > wrote:
> > > > To recap, the idea here was to
On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > On Thu, May 23, 2019, 18:54 Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> > > To recap, the idea here was to change the default authentication
> methods
> >
On Fri, May 24, 2019 at 08:23:57AM -0700, Noah Misch wrote:
> Our sspi auth is a more-general version of peer auth, and it works over TCP.
> It would be a simple matter of programming to support "peer" on Windows,
> consisting of sspi auth with an implicit pg_ident map.
I am not sure that it is
On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> On Thu, May 23, 2019, 18:54 Peter Eisentraut
> wrote:
> > To recap, the idea here was to change the default authentication methods
> > that initdb sets up, in place of "trust".
> >
> > I think the ideal scenario would be to use
On 5/24/19 10:26 AM, Heikki Linnakangas wrote:
> On 24/05/2019 17:02, Jonathan S. Katz wrote:
>> On 5/24/19 9:49 AM, Heikki Linnakangas wrote:
>>> It just prevents MD5 authentication in case a user forces a
>>> new MD5 hash into the system e.g. by changing password_encryption, or by
>>> setting an
On 24/05/2019 17:02, Jonathan S. Katz wrote:
On 5/24/19 9:49 AM, Heikki Linnakangas wrote:
It just prevents MD5 authentication in case a user forces a
new MD5 hash into the system e.g. by changing password_encryption, or by
setting an MD5 password explicitly with ALTER USER.
Cool. Thanks for
On 5/24/19 9:49 AM, Heikki Linnakangas wrote:
> On 24/05/2019 16:01, Stephen Frost wrote:
>> What I was really getting at though was the ability to have multiple
>> authenticator tokens active concurrently (eg: md5 AND SCRAM), with an
>> ability to use either one (idk, md5_or_scram auth method?),
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 24/05/2019 16:01, Stephen Frost wrote:
> >What I was really getting at though was the ability to have multiple
> >authenticator tokens active concurrently (eg: md5 AND SCRAM), with an
> >ability to use either one (idk, md5_or_scram
On 24/05/2019 16:01, Stephen Frost wrote:
What I was really getting at though was the ability to have multiple
authenticator tokens active concurrently (eg: md5 AND SCRAM), with an
ability to use either one (idk, md5_or_scram auth method?), and then
automatically set both on password change
On 5/24/19 9:01 AM, Stephen Frost wrote:
> Greetings,
>
> * Jonathan S. Katz (jk...@postgresql.org) wrote:
>> On 5/24/19 8:33 AM, Stephen Frost wrote:
>>> We need to provide better documentation about how to get from md5 to
>>> SCRAM, in my view. I'm not sure where that should live, exactly.
>>>
On 5/24/19 8:56 AM, Jonathan S. Katz wrote:
> On 5/24/19 8:33 AM, Stephen Frost wrote:
>> * Magnus Hagander (mag...@hagander.net) wrote:
>>> Making the default change away from trust in the source distro will affect
>>> few people.
>>
>> Agreed.
>
> +1
Fewer people, but likely
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 5/24/19 8:33 AM, Stephen Frost wrote:
> > We need to provide better documentation about how to get from md5 to
> > SCRAM, in my view. I'm not sure where that should live, exactly.
> > I really wish we had put more effort into
On 5/24/19 8:33 AM, Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>> The thing that will potentially hit *end users* is when the RPMs, DEBs or
>> Windows Installers switch to SCRAM (because of clients with older drivers).
>
> Agreed. I'm not sure that our
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> The thing that will potentially hit *end users* is when the RPMs, DEBs or
> Windows Installers switch to SCRAM (because of clients with older drivers).
Agreed. I'm not sure that our change to SCRAM as default would actually
make them
On Fri, May 24, 2019 at 2:19 PM Stephen Frost wrote:
> Greetings,
>
> * Joe Conway (m...@joeconway.com) wrote:
> > On 5/24/19 8:13 AM, Stephen Frost wrote:
> > > * Joe Conway (m...@joeconway.com) wrote:
> > >> On 5/23/19 10:30 PM, Stephen Frost wrote:
> > >> > * Tom Lane (t...@sss.pgh.pa.us)
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 5/24/19 8:13 AM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> On 5/23/19 10:30 PM, Stephen Frost wrote:
> >> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> >> "Jonathan S. Katz" writes:
> >> >> > For now I have
On 5/24/19 8:13 AM, Stephen Frost wrote:
> Greetings,
>
> * Joe Conway (m...@joeconway.com) wrote:
>> On 5/23/19 10:30 PM, Stephen Frost wrote:
>> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> >> "Jonathan S. Katz" writes:
>> >> > For now I have left in the password based method to be
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 5/23/19 10:30 PM, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> "Jonathan S. Katz" writes:
> >> > For now I have left in the password based method to be scram-sha-256 as
> >> > I am optimistic about the support
On 2019-05-24 13:48, Joe Conway wrote:
> Are we doing this for pg12?
no
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, 24 May 2019 at 07:48, Joe Conway wrote:
> On 5/23/19 10:30 PM, Stephen Frost wrote:
> > Greetings,
> >
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> "Jonathan S. Katz" writes:
> >> > For now I have left in the password based method to be scram-sha-256
> as
> >> > I am optimistic about
On 5/23/19 10:30 PM, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> "Jonathan S. Katz" writes:
>> > For now I have left in the password based method to be scram-sha-256 as
>> > I am optimistic about the support across client drivers[1] (and FWIW I
>> > have an
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Jonathan S. Katz" writes:
> > For now I have left in the password based method to be scram-sha-256 as
> > I am optimistic about the support across client drivers[1] (and FWIW I
> > have an implementation for crystal-pg ~60% done).
>
> >
"Jonathan S. Katz" writes:
> For now I have left in the password based method to be scram-sha-256 as
> I am optimistic about the support across client drivers[1] (and FWIW I
> have an implementation for crystal-pg ~60% done).
> However, this probably means we would need to set the default
On 5/23/19 6:47 PM, Jonathan S. Katz wrote:
> On 5/23/19 12:54 PM, Peter Eisentraut wrote:
>> On 2019-04-06 20:08, Noah Misch wrote:
> I think we should just change the defaults. There is a risk of warning
> fatigue. initdb does warn about this, so anyone who cared could have
>
On 5/23/19 12:54 PM, Peter Eisentraut wrote:
> On 2019-04-06 20:08, Noah Misch wrote:
I think we should just change the defaults. There is a risk of warning
fatigue. initdb does warn about this, so anyone who cared could have
gotten the information.
>>>
>>> I've been
On Thu, May 23, 2019, 18:54 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-04-06 20:08, Noah Misch wrote:
> >>> I think we should just change the defaults. There is a risk of warning
> >>> fatigue. initdb does warn about this, so anyone who cared could have
> >>> gotten
On 2019-04-06 20:08, Noah Misch wrote:
>>> I think we should just change the defaults. There is a risk of warning
>>> fatigue. initdb does warn about this, so anyone who cared could have
>>> gotten the information.
>>>
>>
>> I've been suggesting that for years, so definite strong +1 for doing
52 matches
Mail list logo
