-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
ingesting: fixup privileges granted during database restore #95466
ingesting: fixup privileges granted during database restore #95466
Conversation
Previously, all schemas and tables that were ingested as part of a database restore would "inherit" the privileges of the database. The database would be granted `CONNECT` for the `public` role and `ALL` to `admin` and `root`, and so all ingested schemas would have `ALL` for `admin` and `root`. Since 21.2 we have moved away from tables/schemas inheriting privileges from the parent database and so this logic is stale and partly incorrect. It is incorrect because the restored `public` schema does not have `CREATE` and `USAGE` granted to the `public` role. These privileges are always granted to `public` schemas of a database and so there is a discrepancy in restore's behaviour. This change simplifies the logic to grant schemas and tables their default set of privileges if ingested via a database restore. It leaves the logic for cluster and table restores unchanged. Release note (bug fix): fixes a bug where a database restore would not grant `CREATE` and `USAGE` on the public schema to the public role Fixes: cockroachdb#95456
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.
thanks for the fix!
Flake is TFTR! bors r=rafiss |
@adityamaru , does it grant CREATE/USAGE to public role blindly? We have customers revoking CREATE and USAGE from the public role |
Yes, a database restore will now grant |
I don't think thats a great idea, that will create surprises. Imagine you are a user. You revoke from this access from the public role. You restore and CREATE/USAGE comes back.. |
Build failed (retrying...): |
When a user revokes these privileges it will be from a |
@data-matt one thing to clarify: for a cluster-level RESTORE, all entities and privileges on those entities will be restored exactly as they were at the time of the BACKUP. But this PR is for the database RESTORE. The scenario you are describing also applies to tables. (If a customer had granted privileges on a table, then does a database RESTORE, the tables will be created with the default privileges and the custom grants will be lost. Is my understanding right @adityamaru?) |
Yeah, I realised my point is moot, since we only restore grants for full cluster backups. So, the users have an action to put the grants back anyway. Please ignore me :D |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 05cfdac to blathers/backport-release-22.1-95466: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.1.x failed. See errors above. error creating merge commit from 05cfdac to blathers/backport-release-22.2-95466: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.2.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Previously, all schemas and tables that were ingested as part of a database restore would "inherit" the privileges of the database. The database would be granted
CONNECT
for thepublic
role andALL
toadmin
androot
, and so all ingested schemas would haveALL
foradmin
androot
. Since 21.2 we have moved away from tables/schemas inheriting privileges from the parent database and so this logic is stale and partly incorrect. It is incorrect because the restoredpublic
schema does not haveCREATE
andUSAGE
granted to thepublic
role. These privileges are always granted topublic
schemas of a database and so there is a discrepancy in restore's behaviour.This change simplifies the logic to grant schemas and tables their default set of privileges if ingested via a database restore. It leaves the logic for cluster and table restores unchanged.
Release note (bug fix): fixes a bug where a database restore would not grant
CREATE
andUSAGE
on the public schema to the public roleFixes: #95456