Postgres Pro
Downloads
Home   >   mailing lists

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all" - Mailing list pgsql-general

From David G. Johnston
Subject Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"
Date
Msg-id CAKFQuwYf0+cXhqTydSaUogeh9n+PgBcZ_joA-V=5F=PVuVmBtQ@mail.gmail.com
Whole thread Raw
In response to Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"  (Bryn Llewellyn <bryn@yugabyte.com>)
Responses Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
Tree view
On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:

About "opinionated package manager", I created my installation by following the steps described here:


 
Yes, apt is opinionated.  And of important note here - its opinions, and the supplemental wrapper scripts it implements to make those opinions works, are outside the scope of what the official PostgreSQL documentation is going to cover.  (This is what the email you linked to is calling pg_wrapper)
 

My experiment shows that my attempt to authorize  as "bob" using "local", "peer" authorization fails when every config file is readable only by "owner" and "group". And it shows that a sufficient fix is to make just "postgresql.conf" readable by "all" (as I believe is the intention). Of course, an alternative fix (in the sesne that it would work) would be to have "postgresql.conf" not readable by all but to put "bob" in the "postgres" group.

All this leads to an obvious question:

«
Given that all of the config files have been made readable by "group" (in contrast to the regime for the data files), what is the intention of this design? In other words, when is it proper to put an O/S user in the "postgres" group? After all, if the answer is "never" than no privileges on "postgres/postgres" files would ever have been granted to "group".
»


I think the intent of the design is for the custom Debian wrapper scripts to be able to read the configuration files for the named version "11" and configuration "main" to find out where certain things like the socket file are being written to.  The argument being the configuration files don't actually contain secret data so reading shouldn't be an issue and can be useful.  Obviously the same does not apply to data files.  On that basis it would indeed make more sense to grant read to "all" rather than try and add users to "postgres" to make the reading of the configuration files work.

David J.

pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"
Next
From: "David G. Johnston"
Date:
Subject: Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"