Re: initdb recommendations

Greetings,

* Noah Misch (noah(at)leadboat(dot)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(at)leadboat(dot)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(dot)eisentraut(at)2ndquadrant(dot)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