On Tue, Nov 1, 2022 at 1:39 PM David G. Johnston <david.g.johns...@gmail.com>
wrote:

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

Reply via email to