Greetings, * Noah Misch (n...@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 <n...@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.eisentr...@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
signature.asc
Description: PGP signature
