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