Re: initdb recommendations

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?

> 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.

> 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.