skip and warn about role mismatch in Maintenance Functions

[jw1u1]

Prevent a mixture of partition owners that lead to permission issues and run_maintenance failures.
Skip Tables that are not owned by the current_role with a warning.

[keithf4]

Just wanted to say thank you for the updates you've done recently. I won't be able to get them in the next release that will hopefully be coming out soon, but I do plan on getting back to more frequent updates again and will review and try and get the ones you've been working on lately incorporated in future releases.

[keithf4]

So I don't think this is accounting for role inheritance/group membership. It's just looking to see if the name of the owner simply matches the name of the current role. If a role is a member of another role, it's considered an owner of all of the same objects.

Also doesn't account for if a superuser is running it, which should be able to succeed as well.

[jw1u1]

Have you ever seen a proper setup with different Owner of Partitions?
You'll usually want to have the same owner.
Of course does run_maintenance work as a superuser but the background worker will fail to drop partitions owned by postgres.
And postgres might have not the same default privileges as inheritance/group membership is not taken into account with default privileges.
Would you like to add a new config parameter "ensure_same_partition_owner"?

[keithf4]

pg_partman already has a setting to force ownership/permissions to be passed down from the parent. If you set inherit_privileges to true in part_config it will do this.

I'm not 100% on what ownership PG does by default for partitioned tables, so I'll have to test it out what happens when another role in the same group or the superuser adds a child. But by default, privileges are not inherited to children so users must go through the parent to access the data. Inheriting privileges allows the users of the table to by-pass the read/write penalties of going through the parent if they happen to know what the child table name is.

[jw1u1]

Owner is the role that executes the maintenance function and that's a mess.
If inherit_privileges=true changes the owner, please make it default.

[keithf4]

An update in 5.5.0 may have a better overall solution for this. A new column was added to part_config that by default is set to the value of the role that created the partition set (maintenance_role). It in turn can be used to create RLS policies to restrict who can see what rows in the maintenance table. So with the right RLS policy in place, a call to run maintenance will only run on partition sets that person has access to.

Even without the RLS policy, a call to run maintenance could be done with a WHERE condition on part_config to only run on the parent tables for a particular owner. Something like the following (untested)

SELECT partman.run_maintenance(parent_table) FROM partman.part_config WHERE maintenance_role = 'my_role';

I think this will be easier to maintain than trying to account for who the current role is and what groups they may be a part of. Apologies for taking so long to get back to this. Life has been busy!

[jw1u1]

That would require a check constraint to prevent a maintenance_role != pg_partman_bgw.role, right?

[jw1u1]

The extension upgrade sets postgres as a default for maintenance_role.
This should be pg_partman_bgw.role or no default.

[keithf4]

That would require a check constraint to prevent a maintenance_role != pg_partman_bgw.role, right?

Not sure I'm following why you think this constraint is needed?

[keithf4]

The extension upgrade sets postgres as a default for maintenance_role. This should be pg_partman_bgw.role or no default.

Actually, it's just setting it to whoever the current_user is. But yeah, i should have the update file set that to pg_partman_bgw.role as part of the update script. Unfortunately I'll have to do that in the next update, so there will be some people that did the update and have that set to postgres. However, it shouldn't affect anyone unless they try to put the RLS policy in place or manually make use of that column as in my example. In those cases, they'll likely have to update that column's value anyway.

Thanks for pointing that out!

[jw1u1]

That would require a check constraint to prevent a maintenance_role != pg_partman_bgw.role, right?

Not sure I'm following why you think this constraint is needed?

To enforce that create_parent can only be run by pg_partman_bgw.role.
Ok, you expect different Table owner.
Will that work with only one pg_partman_bgw.role?
Is the Owner of new partitions altered to the maintenance_role after creation?

run_maintenance should enforce that maintenance_role = CURRENT_USER, too.

[keithf4]

That would require a check constraint to prevent a maintenance_role != pg_partman_bgw.role, right?

Not sure I'm following why you think this constraint is needed?

To enforce that create_parent can only be run by pg_partman_bgw.role. Ok, you expect different Table owner. Will that work with only one pg_partman_bgw.role? Is the Owner of new partitions altered to the maintenance_role after creation?

run_maintenance should enforce that maintenance_role = CURRENT_USER, too.

Please see the top level README for the expected privileges required of the pg_partman_bgw.role and the requirements for not running as a superuser. The simplified recommendation is the BGW role should be the owner of all partition sets so that would mean that the maintenance_role column must match the BGW role. But I cannot strictly enforce that for everyone by default, that has to be managed by the user.

However, it may not be possible for everyone to have a single role managing all partition sets. Especially if people want to allow any sort of multi-tenancy to let multiple roles manage their own partition sets. In that case, the BGW role will have to be a member of any role that owns a partition set. It doesn't matter if the column role and BGW role match or not, so there's no need to enforce it either way. It's a matter of the user managing role privleges and memberships.

If users want to enforce that the role that calls the maintenance functions only has access to specific partition sets in the partman config, that is what an RLS policy can provide.

[jw1u1]

The intention of this patch is to prevent different owners of partitions.
Developers should be able to read the part_config but they tend to forget to execute
set role to database_owner before they create a new partition set or run the maintenance.

Would you accept a patch that enforces current_role = maintenance_role?

[keithf4]

The intention of this patch is to prevent different owners of partitions. Developers should be able to read the part_config but they tend to forget to execute set role to database_owner before they create a new partition set or run the maintenance.

Would you accept a patch that enforces current_role = maintenance_role?

No I cannot accept that patch because it is not always true for everyone's case. That's the intention of the instructions in the README for assigning the partition set owner roles to the maintenance role so the maintenance role has permissions to run on them.