-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes invalid grantor field parsing in grant role propagation #7451
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #7451 +/- ##
=======================================
Coverage 89.59% 89.59%
=======================================
Files 282 282
Lines 60314 60318 +4
Branches 7512 7513 +1
=======================================
+ Hits 54037 54042 +5
+ Misses 4121 4119 -2
- Partials 2156 2157 +1 |
Do we still plan to work on this PR @gurkanindibay / @halilozanakgul? |
I have plans to work on it. However, I can not get answer for the errors here. There are some intentional tests here in which non-distributed role is being used. After the fix, tests fail since the non-distributed field is being used as grantor |
@@ -107,7 +107,7 @@ RESET ROLE; | |||
|
|||
SET citus.enable_create_role_propagation TO ON; | |||
|
|||
GRANT dist_role_3 TO non_dist_role_3; | |||
GRANT dist_role_3 TO non_dist_role_3 granted by postgres; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this test? Isn't the current user already postgres
? And we are not looking at a propagated query or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to test_admin_role
@@ -486,7 +486,6 @@ AppendGrantRoleStmt(StringInfo buf, GrantRoleStmt *stmt) | |||
appendStringInfo(buf, "%s ", stmt->is_grant ? " TO " : " FROM "); | |||
AppendRoleList(buf, stmt->grantee_roles); | |||
AppendGrantWithAdminOption(buf, stmt); | |||
AppendGrantedByInGrantForRoleSpec(buf, stmt->grantor, stmt->is_grant); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are multiple AppendGrantedByInGrantForRoleSpec added there which causes error
@@ -240,10 +242,11 @@ SELECT roleid::regrole::text AS role, member::regrole::text, (grantor::regrole:: | |||
role | member | grantor | admin_option | |||
--------------------------------------------------------------------- | |||
dist_role_1 | dist_role_2 | t | f | |||
dist_role_3 | non_dist_role_3 | t | f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change the query into this so that we can verify whether we set grantor properly?
SELECT roleid::regrole::text AS role, member::regrole::text, grantor::regrole::text, admin_option FROM pg_auth_members WHERE roleid::regrole::text LIKE '%dist\_%' ORDER BY 1, 2;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can not since grantor for pg 14 and pg 15 is different from pg16. I think that's why they put such check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the difference?
There is probably some valid reason for this change but it kind of makes the test useless, since the grantor will almost always be postgres
in our tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now added test_admin_role into viable grantor list to make grantor t for the list.
@@ -240,10 +242,11 @@ SELECT roleid::regrole::text AS role, member::regrole::text, (grantor::regrole:: | |||
role | member | grantor | admin_option | |||
--------------------------------------------------------------------- | |||
dist_role_1 | dist_role_2 | t | f | |||
dist_role_3 | non_dist_role_3 | t | f | |||
dist_role_3 | non_dist_role_3 | f | f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also add another test to make sure that we properly set grantor on other nodes too, maybe by using:
SELECT result FROM run_command_on_all_nodes(
$$
SELECT json_agg(q.* ORDER BY member) FROM (
SELECT member::regrole::text, grantor::regrole::text, admin_option
FROM pg_auth_members WHERE roleid::regrole::text = 'dist_role_3'
) q;
$$
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added run_all_nodes into the query
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the test to see the grantor for the new statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except that one last test
@@ -228,22 +228,41 @@ SET ROLE non_dist_role_1; | |||
GRANT dist_role_1 TO dist_role_2; | |||
RESET ROLE; | |||
SET citus.enable_create_role_propagation TO ON; | |||
GRANT dist_role_3 TO non_dist_role_3; | |||
create role test_admin_role; | |||
grant dist_role_3 to test_admin_role with admin option; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change this into this so that we can actually test whether we propagate grantor. The latter grant stmt doesn't test this because of the none distributed role.
grant dist_role_3 to test_admin_role with admin option; | |
grant dist_role_3 to test_admin_role granted by ... with admin option; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggested change is the same as the current code. Do I miss sth?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added test_admin_role just for granted by. I added a distributed role grant on next step. Is it sufficient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding this GRANT stmt:
GRANT dist_role_3 TO dist_role_4 granted by test_admin_role;
We get different outputs on different nodes:
"member":"dist_role_4","role":"dist_role_3","grantor":"test_admin_role","admin_option":false}
...
"member":"dist_role_4","role":"dist_role_3","grantor":"postgres","admin_option":false}
...
"member":"dist_role_4","role":"dist_role_3","grantor":"postgres","admin_option":false}
So I got confused a bit, is this really expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the bug related to metadata_sync wrong grantor issue. I will fix it in another PR as we have talked
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right . grantor was being set to NULL. Fixed it.
Description format seems incorrect, could you improve this based on our usual format? |
Can we follow our usual description format, as in:
|
…itus into missing_grantor_sync
/* | ||
* Postgres don't seem to use the grantor. Even dropping the grantor doesn't | ||
* seem to affect the membership. If this changes, we might need to add grantors | ||
* to the dependency resolution too. For now we just don't propagate it. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now except what this comment states ..
As I mentioned earlier, could you please talk to @halilozanakgul to decide:
a) How hard it is to accomplish what this comment states, or,
b) If we're taking the risk of " role does not exist" errors coming from workers when the grantor is not a distributed role given that we expect such conditions to be rare.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm this, but let's fix metadata syncing issue in this PR too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed the grantor propagation other than missing grantor before metadata sync phase. In dependency resolution phase, if grantor has admin rolesi then it can not be propagated. I think it is not a must for our tasks. I can open an issue and continue working on that task with suitable priority
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onurctirtir we discussed the issue in the meeting on 02/12/2024. Now grantor is not being taken from dependency resolution when it has an admin option on it.
I need to investigate further. Right now, since we have blocked issues. We decided to keep this issue as it is and after unblock all issues.
In parallel, I will start investigating the issue with the issue #7488
Thanks.
Co-authored-by: Onur Tirtir <onurcantirtir@gmail.com>
DESCRIPTION: Fixes a bug that breaks distributed GRANT statements with grantor option
In this issue 3 issues are being solved:
1.Correcting the erroneous appending of multiple granted by in the deparser.
2Adding support for grantor (granted by) in grant role propagation.
3. Implementing grantor (granted by) support during the metadata sync grant role propagation phase.
Limitations: Currently, the grantor must be created prior to the metadata sync phase. During metadata sync, both the creation of the grantor and the grants given by that role cannot be performed, as the grantor role is not detected during the dependency resolution phase.