On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn <bryn@xxxxxxxxxxxx> 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.
