Обсуждение: initdb recommendations

Given some of the recent hubbub and analysis of CVE entries, one part of
the documentation[1] that could be further clarified is what initdb does
by default, i.e. creates a cluster where users can connect with trust
authentication. While this may be great for people who are hacking or
running PostgreSQL in a trusted local environment, this may not make
sense for many (most?) other systems.

The attached patch clarifies this fact and adds a "warning" box just
below the initdb examples that provides recommendations to create a more
secure environment. It also removes the section that discusses this
below the part that discusses securing the directory, as really this
explanation should go right after the "initdb" call.

(There could be an additional discussion about whether or not we want to
change the default behavior for initdb, but I would suggest that a safe
starting point would be to ensure we call this out)

Credits to Magnus for pointing this out, and Tom + Andrew D. for review
before posting to list.

Jonathan

[1] https://www.postgresql.org/docs/current/creating-cluster.html

On 2019-04-05 18:11, Jonathan S. Katz wrote:
> (There could be an additional discussion about whether or not we want to
> change the default behavior for initdb, but I would suggest that a safe
> starting point would be to ensure we call this out)

I think we should just change the defaults.  There is a risk of warning
fatigue.  initdb does warn about this, so anyone who cared could have
gotten the information.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/5/19 4:58 PM, Peter Eisentraut wrote:
> On 2019-04-05 18:11, Jonathan S. Katz wrote:
>> (There could be an additional discussion about whether or not we want to
>> change the default behavior for initdb, but I would suggest that a safe
>> starting point would be to ensure we call this out)
>
> I think we should just change the defaults.  There is a risk of warning
> fatigue.  initdb does warn about this, so anyone who cared could have
> gotten the information.

It might actually be a combination of both updating the defaults and
modifying the documentation.

If we introduce better defaults, we'll need an explanation of what the
defaults are and why they are as such.

If we don't, we certainly need to warn the user what's happening. The
way it's currently written, it's very easy to miss.

I also don't see how it's warning fatigue when it's both a) a feature
that could put your system into a vulnerable state if you're not careful
and b) the only warning on that page.

Jonathan

On Sat, Apr 06, 2019 at 11:35:44AM +0200, Magnus Hagander wrote:
> On Fri, Apr 5, 2019 at 10:58 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> > On 2019-04-05 18:11, Jonathan S. Katz wrote:
> > > (There could be an additional discussion about whether or not we want to
> > > change the default behavior for initdb, but I would suggest that a safe
> > > starting point would be to ensure we call this out)
> >
> > I think we should just change the defaults.  There is a risk of warning
> > fatigue.  initdb does warn about this, so anyone who cared could have
> > gotten the information.
> >
> 
> I've been suggesting that for years, so definite strong +1 for doing that.

+1

> If it's something that annoys backend developers who initdb very often, I
> suggest we add an environment variable to override it. But I'm not sure
> that's really necessary -- creating a shell alias or similar is easy to do,
> and most have probably already done so for other reasons.

I, for one, do most initdb runs via a script and wouldn't use such an
environment variable.

On 2019-04-05 18:11, Jonathan S. Katz wrote:
> +    <para>
> +      We recommend using the <option>-W</option>, <option>--pwprompt</option>,
> +      or <option>--pwfile</option> flags to assign a password to the database
> +      superuser, and to override the <filename>pg_hba.conf</filename> default
> +      generation using <option>-auth-local peer</option> for local connections,
> +      and <option>-auth-host scram-sha-256</option> for remote connections. See
> +      <xref linkend="client-authentication"/> for more information on client
> +      authentication methods.
> +    </para>

As discussed on hackers, we are not ready to support scram-sha-256 out
of the box.  So this advice, or any similar advice elsewhere, would need
to recommend "md5" as the setting --- which would probably be embarrassing.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/8/19 8:25 AM, Peter Eisentraut wrote:
> On 2019-04-05 18:11, Jonathan S. Katz wrote:
>> +    <para>
>> +      We recommend using the <option>-W</option>, <option>--pwprompt</option>,
>> +      or <option>--pwfile</option> flags to assign a password to the database
>> +      superuser, and to override the <filename>pg_hba.conf</filename> default
>> +      generation using <option>-auth-local peer</option> for local connections,
>> +      and <option>-auth-host scram-sha-256</option> for remote connections. See
>> +      <xref linkend="client-authentication"/> for more information on client
>> +      authentication methods.
>> +    </para>
>
> As discussed on hackers, we are not ready to support scram-sha-256 out
> of the box.  So this advice, or any similar advice elsewhere, would need
> to recommend "md5" as the setting --- which would probably be embarrassing.

Well, it's less embarrassing than trust, and we currently state:

"Also, specify -A md5 or -A password so that the default trust
authentication mode is not used"[1]

We could also modify it to say :

"and <option>-auth-host scram-sha-256</option> for remote connections if
 your client supports it, otherwise <option>-auth-host md5</option>"

Jonathan

[1] https://www.postgresql.org/docs/current/creating-cluster.html

On 4/8/19 8:44 AM, Magnus Hagander wrote:
> On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> wrote:
>
>     On 4/8/19 8:25 AM, Peter Eisentraut wrote:
>     > On 2019-04-05 18:11, Jonathan S. Katz wrote:
>     >> +    <para>
>     >> +      We recommend using the <option>-W</option>,
>     <option>--pwprompt</option>,
>     >> +      or <option>--pwfile</option> flags to assign a password to
>     the database
>     >> +      superuser, and to override the
>     <filename>pg_hba.conf</filename> default
>     >> +      generation using <option>-auth-local peer</option> for
>     local connections,
>     >> +      and <option>-auth-host scram-sha-256</option> for remote
>     connections. See
>     >> +      <xref linkend="client-authentication"/> for more
>     information on client
>     >> +      authentication methods.
>     >> +    </para>
>     >
>     > As discussed on hackers, we are not ready to support scram-sha-256 out
>     > of the box.  So this advice, or any similar advice elsewhere,
>     would need
>     > to recommend "md5" as the setting --- which would probably be
>     embarrassing.
>
>     Well, it's less embarrassing than trust, and we currently state:
>
>
> Yes. Much less.
>
>
>     "Also, specify -A md5 or -A password so that the default trust
>     authentication mode is not used"[1]
>
>     We could also modify it to say :
>
>     "and <option>-auth-host scram-sha-256</option> for remote connections if
>      your client supports it, otherwise <option>-auth-host md5</option>"
>
>
> That would be the best from a correctness, but if of course also makes
> things sound more complicated. I'm not sure where the right balance is
> there.

We could link here[1] from the docs on the line for "client supports it"

Jonathan

[1] https://wiki.postgresql.org/wiki/List_of_drivers