(David and Ian, I'm resending this because, I see that I managed to omit "pgsql-general@xxxxxxxxxxxxxxxxxxxx" from the addressee list. So, of course, it didn't show up in the "pgsql-general" archive.) barwick@xxxxxxxxx wrote:david.g.johnston@xxxxxxxxx:
Thanks. David and Ian. I'll take this: If GRANTED BY is specified, the grant is recorded as having been done by the specified role. A user can only attribute a grant to another role if they possess the privileges of that role. The role recorded as the grantor must have ADMIN OPTION on the target role, unless it is the bootstrap superuser. When a grant is recorded as having a grantor other than the bootstrap superuser, it depends on the grantor continuing to possess ADMIN OPTION on the role; so, if ADMIN OPTION is revoked, dependent grants must be revoked as well. from an upcoming version of the "grant" statement doc, to be a sufficient establishment of the canonical status of the term of art that I sought. I'll adopt the term "bootstrap superuser" (and not plain "bootstrap user") and I'll assume that everybody on this list (at least anybody who might answer my questions) shares the same, and immediate, understanding of the term—which implies this:
[*] I see that, in my Ubuntu installation, critical programs like "postgres" itself, "initdb", "pg_ctl", "pg_dump" and so on are owned by "root". The fact that the "bootstrap superuser" term of art denotes a matching pair of two principals (an O/S user and a within-cluster role) means that some sentences will require extra verbiage to identify which half of the pair the sentence treats. I'm open to suggestions. But I'll start with these these I'm corrected: the "bootstrap (regular) OS-user" and the "bootstrap within cluster superuser role". Sadly, the fact that "super" is baked into the term of art makes it difficult to name the O/S half of the phenomenon. I can now characterize what I'd observed more clearly, thus: only a bootstrap super user (as defined above) can start a session without mentioning the name of the database to which to connect and the name of the within-cluster role to connect as—and without supplying a password. And it can do this only from as O/S session where the effective O/S user is the bootstrap superuser. It seems, too, that one would be stupid to call the bootstrap superuser anything other than "postgres". Notice that this implies that the typical macOS regime (where my bootstrap super user is called "Bllewell" and has to be double-quoted in SQL, and yours is called "sagrawal") is, indeed, stupidly unconventional. All this implies a little test. Here, I'll save typing by saying that my bootstrap superuser is called "postgres". I created a second database in a freshly created cluster called "x". And then, from the O/S, I tried this: psql -d x That worked fine. But, having said this, it would seem that it would be so very unconventional (given that you've already agreed to call your bootstrap superuser "postgres", not to make a database called "postgres" available too. (I tested that by dropping my "postgres" database. (This is the freedom that a VM with a nice snapshot together with the ability to start afresh with "initdb" brings.) Now, the bare "psql" causes the error "FATAL: database "postgres" does not exist". |
