Grant minimum required permissions for non-superuser usage

[ardentperf]

Version 1.5.2 of pg_repack allowed non-superusers to repack their own tables by updating privilege checks in several backend functions (PR #431). This capability is important for environments where platform teams manage postgres installation and upgrades, but non-superusers directly manage their own schemas and tables including repacks. However version 1.5.2 did not grant the actual privileges to run pg_repack to non-superusers. This change adds the missing grants and allows table owners to use pg_repack with --no-superuser-check. This also adds a successful non-superuser test case, which was missing before.

Importantly, table ownership permissions still prevent users from accessing intermediate repack data and log tables of other users. (cf https://github.com/ardentperf/pg_repack_isolation/blob/main/test_multiuser_isolation.log )

[za-arthur]

Thank you @ardentperf,

Would it make sense to grant permissions only to pg_maintain role instead of broad public? Although this would work only for Postgres 17+ I don't think it makes sense to grant access to everybody.

Moreover we could allow in pg_repack to repack to those who has pg_maintain privileges, in addition to owners.

[za-arthur]

There is a relevant PR #451

[harinath001]

@za-arthur @ardentperf

this patch #451 offers a more secure and maintainable solution by leveraging PostgreSQL's native trusted extension mechanism (available in PostgreSQL 13+).

the approach uses the @extowner@ placeholder to grant permissions exclusively to the extension owner, allowing controlled delegation without exposing repack capabilities to all users by default. it better aligns with PostgreSQL's security model for trusted extensions, where the extension owner (who has explicit CREATE privileges on the database) becomes the natural administrator of the extension and schema.

Also, we don't need to modify any test cases as the patch is backward compatible.

let me know if this looks good, appreciate any reviews on the PR and waiting for inclusion of the patch in future releases.

Thanks.

[ardentperf]

@za-arthur pg_repack is effectively a substitute for vacuum full with less downtime. This is the biggest use case for pg_repack. I think the most sensible thing here is that it should operate with the same permission model - if someone has privileges to do a vacuum full then they should have privs to do repack. Is there a specific threat we're protecting against by blocking pg_repack access from people who can do a vacuum full?

Would it make sense to grant permissions only to pg_maintain role instead of broad public? Although this would work only for Postgres 17+ I don't think it makes sense to grant access to everybody.

Version 1.5.2 of pg_repack allowed non-superusers to repack their own tables (but not other people's tables) by updating privilege checks in several backend functions. Importantly, table ownership permissions still prevent users from accessing intermediate repack data and log tables of other users. This proposed PR does not grant access to public to successfully repack arbitrary tables.

The third regression test verifies that the nosuper user cannot repack a table that isn't owned by nosuper. This being said, it wouldn't hurt for someone to double-check my work here and have a second set of eyes confirm that there aren't any accidental corner cases allowing a non-superuser to successfully repack tables that couldn't already be the target of a vacuum full. I don't think we need a regression test with two different non-superusers, as the third test should provide sufficient coverage for now? Are there other privilege model situations worth adding regression tests for? Should we add more comments to the regression tests explaining why we intentionally want the third test to fail and prove the security model works?