From: Stephen Frost <sfrost@snowman.net>
To: Noah Misch <noah@leadboat.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Jonathan S. Katz <jkatz@postgresql.org>
Subject: Re: initdb recommendations
Date: Mon, 3 Jun 2019 17:20:42 -0400
Message-ID: <20190603212042.GR2480@tamriel.snowman.net> (raw)
In-Reply-To: <20190603005539.GA116225@gust.leadboat.com>
References: <bec17f0a-ddb1-8b95-5e69-368d9d0a3390@postgresql.org>
<f27d3170-76cf-4afb-1e1a-b1059295ec8d@2ndquadrant.com>
<CABUevExMizVYea9zaHBte66u9KipEgfwcsaE9spfqK9iYRST_g@mail.gmail.com>
<20190406180839.GA1921989@rfd.leadboat.com>
<96389374-9454-d26d-6f79-7c7b15ec14bd@2ndquadrant.com>
<CABUevExdgYkaikDHFtkibqJ=pEamnqnTW_DDuBLoRmtsd9KR8w@mail.gmail.com>
<20190524152357.GC1624191@rfd.leadboat.com>
<CABUevEyNWb4ifBkB_6meRUtQ+WNynGf_SE_bgFKOY9fpnmtR+w@mail.gmail.com>
<20190603005539.GA116225@gust.leadboat.com>
Greetings,
* Noah Misch (noah@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 <noah@leadboat.com> wrote:
> > > On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > > > On Thu, May 23, 2019, 18:54 Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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) for host.
> > > > >
> > > > > Looking through the buildfarm, I gather that the only platforms that
> > > > > don't support peer are Windows, AIX, and HP-UX. I think we can probably
> > > > > figure out some fallback or alternative default for the latter two
> > > > > platforms without anyone noticing. But what should the defaults be on
> > > > > Windows? It doesn't have local sockets, so the lack of peer wouldn't
> > > > > matter. But is it OK to default to a password method, or would that
> > > > > upset people particularly?
> > > >
> > > > I'm sure password would be fine there. It's what "everybody else" does
> > > > (well sqlserver also cord integrated security, but people are used to it).
> > >
> > > 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. Nonetheless, I agree
> > > password would be fine.
> >
> > I hope oyu don't mean "make peer use sspi on windows". I think that's a
> > really bad idea from a confusion perspective.
>
> I don't mean "make peer an alias for SSPI", but I do mean "implement peer on
> Windows as a special case of sspi, using the same Windows APIs". To the
> client, "peer" would look like "sspi". If that's confusion-prone, what's
> confusing about it?
I tend to agree with Magnus here. It's confusing because 'peer' in our
existing parlance discusses connections over a unix socket, which
certainly isn't what's happening on Windows. I do agree with the
general idea of making SSPI work by default on Windows.
> > However, what we could do there is have the defaut pg_hba.conf file contain
> > a "reasonable setup using sspi" that's a different story.
>
> That's another way to do it. Currently, to behave like "peer" behaves, one
> hard-codes the machine's SSPI realm into pg_ident.conf. If we introduced
> pg_ident.conf syntax to remove that need (e.g. %MACHINE_REALM%), that approach
> would work.
I would be in favor of something like this, provided the variables are
defined in such a way that we could avoid conflicting with real values
(and remember that you'd need a regexp in pg_ident.conf for this to
work...). %xyz%, while supporting %% to mean a literal percent, seems
likely to work. Not sure if that's what you were thinking though.
> > But I wonder if that isn't better implemented at the installer level. I
> > think we're better off doing something like scram as the config when you
> > build from source ,and then encourage installers to do other things based on
> > the fact that they know more information about the setup (such as usernames
> > actually used).
>
> If initdb has the information needed to configure the recommended
> authentication, that's the best place to do it, since there's one initdb and
> many installers. So far, I haven't seen a default auth configuration proposal
> involving knowledge of OS usernames or other information initdb lacks.
I agree with doing it at initdb time.
Note that the current default auth configuration (to some extent) does
depend on the OS username- but that's also something that initdb knows,
and therefore it isn't an issue here. I don't see a reason that we
wouldn't be able to have initdb handle this.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: sfrost@snowman.net, noah@leadboat.com, magnus@hagander.net, peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgresql.org, jkatz@postgresql.org
Subject: Re: initdb recommendations
In-Reply-To: <20190603212042.GR2480@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox