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"

On Tue, Nov 1, 2022 at 1:39 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> 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.
David J.