On Tue, Nov 1, 2022 at 1:39 PM David G. Johnston <david.g.johnston@xxxxxxxxx> wrote:
On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn <bryn@xxxxxxxxxxxx> wrote: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.
Also, per the initdb documentation:
For security reasons the new cluster created by <command>initdb</command>
will only be accessible by the cluster user by default. The
<option>--allow-group-access</option> option allows any user in the same
group as the cluster owner to read files in the cluster. This is useful
for performing backups as a non-privileged user.
will only be accessible by the cluster user by default. The
<option>--allow-group-access</option> option allows any user in the same
group as the cluster owner to read files in the cluster. This is useful
for performing backups as a non-privileged user.
David J.
