Date: Mon, 3 Jun 2019 17:20:42 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Noah Misch <noah@leadboat.com>
Cc: Magnus Hagander <magnus@hagander.net>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	"Jonathan S. Katz" <jkatz@postgresql.org>
Subject: Re: initdb recommendations
Message-ID: <20190603212042.GR2480@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="xHTUIiWqaPwZ9IpM"
Content-Disposition: inline
In-Reply-To: <20190603005539.GA116225@gust.leadboat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--xHTUIiWqaPwZ9IpM
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@2ndq=
uadrant.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 s=
ome
> > > > > appropriate password method (being discussed elsewhere) for host.
> > > > >
> > > > > Looking through the buildfarm, I gather that the only platforms t=
hat
> > > > > don't support peer are Windows, AIX, and HP-UX.=A0 I think we can=
 probably
> > > > > figure out some fallback or alternative default for the latter two
> > > > > platforms without anyone noticing.=A0 But what should the default=
s be on
> > > > > Windows?=A0 It doesn't have local sockets, so the lack of peer wo=
uldn't
> > > > > matter.=A0 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" d=
oes
> > > > (well sqlserver also cord integrated security, but people are used =
to it).
> > >=20
> > > Our sspi auth is a more-general version of peer auth, and it works ov=
er TCP.
> > > It would be a simple matter of programming to support "peer" on Windo=
ws,
> > > consisting of sspi auth with an implicit pg_ident map.=A0 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.
>=20
> 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 con=
tain
> > a "reasonable setup using sspi" that's a different story.
>=20
> That's another way to do it.  Currently, to behave like "peer" behaves, o=
ne
> 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 app=
roach
> 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 bas=
ed on
> > the fact that they know more information about the setup (such as usern=
ames
> > actually used).
>=20
> 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 pro=
posal
> 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

--xHTUIiWqaPwZ9IpM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJc9Y8qAAoJEO1sijiDR2RVUGMQAIWU1AoQLL6Cvl9acanz1P0K
8wML4S1z0IpXZSh4Ho+H3lDRMawF/Pvsas3veZcdzQp0o42uOD+jVHd+EUMpdUeL
ldkDEF5KMzbucmwrP2JnMLuD+b+DWW52cnoBlXuQEJXPefhKycA1JsEhpKN2cfd1
4FK2Tki56KGJteXnwH0iAwVRPMWD3jotCcl9/XbW896myPTm6MH03NEri8shy2O1
hj7kvU2egsBPGNyDk4h0nhj134gqvKojPmvwkL/QnC5vBxOKfFhCuSUjcf/Tw4tt
CKRjLeSqQUAWwYDdDucA0cwga1J9XRLcZDvC6xWVNpg82gwB+pypuDH5nnkw5PP6
DvOSJ92uTzL0kwIjY13Gw3jk7RhvmjRJV9gI0KQ2SYJC9t5a4z5UEAcx5O2cVyTr
/j6Saz7nhg9n9KGe7y9T+k/b6p+wEtoHMLszHlgcgp80xvV1heqD4mgYNhV8td3l
2K6SMt1oSgEDUR1v2/iRRVY4KmkszDCpN0DoUeY7AfYUG6brF5M29wlhS4E3I4iV
dgrBGPLyP1i25ALwdaeAOL/9i/RbU42R/rMC0F8IyHs/exYorYd10XlHLt+varhI
7p07gK7oYaE7FYKBAuIwOWkWeK2+W1k61UvjyEsIz8nViG5nkawdqVDYrIRT4OyY
RIK0qQ0V4kG3eN3IGDuy
=540I
-----END PGP SIGNATURE-----

--xHTUIiWqaPwZ9IpM--