david.g.johnston@xxxxxxxxx wrote:bryn@xxxxxxxxxxxx wrote: I meant only to ask a question—and not to pre-judge anything. I should have thought more carefully about its wording. (I'm thinking specifically of a PG installation on Linux—and only that.) About "opinionated package manager", I created my installation by following the steps described here: My aim is simply to conform to recommended practice. When I've said (like I believe that I have) that I didn't get a chance, during the flow, to specify <this or that>, my intention was only to note this fact and to imply that what I got without any intervention coincided with the recommended practice. This suits me. I'm going to need to use a term to denote the O/S user that very often ends up with the name "postgres". I don't know what the official term is. I'll simply say "postgres" here. I haven't yet found an overview of the set of files that jointly implement a freshly installed PG system. But, of course, I've noticed where critical directories are. For example: /usr/lib/postgresql/11/bin Lots of familiar names, like "initdb" are found there. They all have owner/group "root". And they're all executable by "all". The point has been made that its not who owns them that matters but, rather, what the effective user ID is at execution time. I can therefore ignore these for the purpose of my present question. In contrast, on (my) "data_directory" (I have just one) here: /var/lib/postgresql/11/main I see that every file has owner/group "postgres/postgres". The "owner" has all privileges. And each of "group" and "all" have no privileges. This doesn't seem at all surprising. But it does indicate that whatever privileges some critical file has (anywhere), the set has been determined by design. There are several "*.conf" files on the same directory as the "config_file ". For me, it's this: /etc/postgresql/11/main These, too, all have owner/group "postgres/postgres" — and "postgres" has all meaningful privileges (presumably "execute" means nothing for a text config file). But "group” has only "read" on them all and "all" has no privileges except (I believe) for “postgresql.conf"—which is readable by all. I mentioned that I'll presently re-do my PG installation from scratch. Then I'll record the permissions that all the config files are set up with and know for sure. I looked in this section: 20.2. File Locations But "permission" isn't found on the page. Anyway, it's only natural to assume that privileges on all of the "postgres/postgres" files have been determined in accordance with a deliberate design. The docs tell me to edit certain of these files to achieve certain intended effects. I've done this—by authorizing as the "postgres" O/S user. So there's an inevitable risk (at least for me) that I might have changed some permissions accidentally. I've observed that, for my present use case (enable "local", "peer" authentication for an O/S user other than "postgres), the authorization attempt fails unless that user can read one critical config file. I just did a careful test with the brand-new O/S user "bob". Here's what "id" shows: id=1003(bob) gid=1003(bob) groups=1003(bob) uid=1001(postgres) gid=1001(postgres) groups=1001(postgres),27(sudo),114(ssl-cert) <aside> I know that I've been told off for allowing "sudo" for "postgres". I'm only experimenting on my laptop. But I want to be able to stop the server, delete the datafiles, create a new cluster, and then start that using a single script. I can't use "pg_ctl stop/start" because it expects to find its config files on the data directory. (That's a different story. And I'm not ready to ask about that yet.) So I use "sudo systemctl stop/start postgresql" because this method looks in the right place for the config files. </aside> Here's what my "pg_hba.conf" has: local all bob peer 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". » |
