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.