Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUC3E-0002o5-Rv for pgsql-hackers@arkaria.postgresql.org; Fri, 24 May 2019 15:24:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hUC3D-0003vG-Dy for pgsql-hackers@arkaria.postgresql.org; Fri, 24 May 2019 15:24:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUC3C-0003v9-TJ for pgsql-hackers@lists.postgresql.org; Fri, 24 May 2019 15:24:07 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUC39-0004Cb-VX for pgsql-hackers@postgresql.org; Fri, 24 May 2019 15:24:06 +0000 Received: by mail-pf1-x443.google.com with SMTP id c6so5520222pfa.10 for ; Fri, 24 May 2019 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WYOpnNhKyX+0s+lP5AE4hpCgVNBgQPj6b4PQaP9t6Y0=; b=YMG90oyplWdB7vBQDuSO30iWGf/CogCTpH39/eiInWYh1mvVn8HZ1jqtRkv8tY414Y KqCqbQQ8mrHFJfCTDlImljnTfbz0MCSN0oaxGAu4tqeHUSLegZoSeCKiBXPg4C2Y2QWf 6EimVNaPbfXO+dejyTJ5g5pgOhAdhqI3fcESo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WYOpnNhKyX+0s+lP5AE4hpCgVNBgQPj6b4PQaP9t6Y0=; b=PwDbz3qYGPnGv8BDYf0zM1mp7MgOLXw8j1dGAht5y73lYwIY4wu0cQSxSdUPfNfgTh ASeWJZ6n+37AEWZD6M3mjd+JQcKWn+3aqN0QSdMdTFWvts41iW6ZCU+4eXHV55GDilAW 5rYAxa+luB19hljjLlwN2YfzGJXqi4LwVlkOtCroqa2bwd6yMX1F8HwVOvs93De82bAz phvkvIx+im20BYKFVPgPsFWOdsx90jeS/Cx0ABLDgj0Hu/5U/pevZBNrQtNhR9dj1Ndz lcFLtk8NLwb9IyG4KZeMP+z0MMTjidtlVClM/iug8wDHXEM7j61FejlbYcbSnqAJ9lUS WZDw== X-Gm-Message-State: APjAAAVBT3vEZIu0mD61mfqYQw5H7FWcckjEFSuU90YK+bclu0KdZST9 TeXeVqOxOb2KSQUKM7FoKvkMaQ== X-Google-Smtp-Source: APXvYqyNMflsN6hrWjCji69XN9WNXdja8NsmMKRxYEiNNP6s2WiOtVqzrPEIz4VpU55OELaATHKpKw== X-Received: by 2002:a63:4753:: with SMTP id w19mr33244147pgk.421.1558711440938; Fri, 24 May 2019 08:24:00 -0700 (PDT) Received: from rfd.leadboat.com (108-233-125-46.lightspeed.sntcca.sbcglobal.net. [108.233.125.46]) by smtp.gmail.com with ESMTPSA id i12sm3021522pfd.33.2019.05.24.08.23.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 08:23:59 -0700 (PDT) Date: Fri, 24 May 2019 08:23:57 -0700 From: Noah Misch To: Magnus Hagander Cc: Peter Eisentraut , PostgreSQL-development , "Jonathan S. Katz" Subject: Re: initdb recommendations Message-ID: <20190524152357.GC1624191@rfd.leadboat.com> References: <20190406180839.GA1921989@rfd.leadboat.com> <96389374-9454-d26d-6f79-7c7b15ec14bd@2ndquadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote: > On Thu, May 23, 2019, 18:54 Peter Eisentraut 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.