Re: almost-super-user problems that we haven't fixed yet
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-01-17T18:42:30Z
Lists: pgsql-hackers
On Mon, Jan 16, 2023 at 09:06:10PM -0500, Robert Haas wrote: > On Mon, Jan 16, 2023 at 5:37 PM Nathan Bossart <nathandbossart@gmail.com> wrote: >> On Mon, Jan 16, 2023 at 02:29:56PM -0500, Robert Haas wrote: >> > 4. You can reserve a small number of connections for the superuser >> > with superuser_reserved_connections, but there's no way to do a >> > similar thing for any other user. As mentioned above, a CREATEROLE >> > user could set connection limits for every created role such that the >> > sum of those limits is less than max_connections by some margin, but >> > that restricts each of those roles individually, not all of them in >> > the aggregate. Maybe we could address this by inventing a new GUC >> > reserved_connections and a predefined role >> > pg_use_reserved_connections. >> >> I've written something like this before, and I'd be happy to put together a >> patch if there is interest. > > Cool. I had been thinking of coding it up myself, but you doing it works, too. Alright. The one design question I have is whether this should be a new set of reserved connections or replace superuser_reserved_connections entirely. If we create a new batch of reserved connections, only roles with privileges of pg_use_reserved_connections would be able to connect if the number of remaining slots is greater than superuser_reserved_connections but less than or equal to superuser_reserved_connections + reserved_connections. Only superusers would be able to connect if the number of remaining slots is less than or equal to superuser_reserved_connections. This helps avoid blocking new superuser connections even if you've reserved some connections for non-superusers. Іf we replace superuser_reserved_connections, we're basically opening up the existing functionality to non-superusers, which is simpler and probably more in the spirit of this thread, but it doesn't provide a way to prevent blocking new superuser connections. My preference is the former approach. This is closest to what I've written before, and if I read your words carefully, it seems to be what you are proposing. WDYT? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve several permission-related error messages.
- de4d456b406b 16.0 landed
-
Integrate superuser check into has_rolreplication()
- 442f8700656b 16.0 landed
-
Small code simplification
- 3b7cd8c690f2 16.0 landed
-
Adjust interaction of CREATEROLE with role properties.
- f1358ca52dd7 16.0 landed
-
Add new GUC reserved_connections.
- 6e2775e4d4e4 16.0 landed
-
Rename ReservedBackends variable to SuperuserReservedConnections.
- fe00fec1f5d7 16.0 landed
-
Update docs and error message for superuser_reserved_connections.
- 6c1d5ba48678 16.0 landed
-
Add new GUC createrole_self_grant.
- e5b8a4c098ad 16.0 cited
-
Restrict the privileges of CREATEROLE users.
- cf5eb37c5ee0 16.0 cited
-
Add a SET option to the GRANT command.
- 3d14e171e9e2 16.0 cited