#36843: RenamePermission might operate on unrelated models
---------------------------------+---------------------------------------
Reporter: Jacob Walls | Owner: Jacob Walls
Type: Bug | Status: assigned
Component: contrib.auth | Version: 6.0
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+---------------------------------------
Description changed by Jacob Walls:
Old description:
> As of Django 6.0 (#27489), when a migration contains a `RenameModel`
> operation, ephemeral `RenamePermission` operations are injected to sync
> the name & codename of the model's permission records.
>
> As mentioned in
> https://github.com/django/django/pull/20339#discussion_r2653481704, we
> discovered that the ephemeral operation might operate on unrelated
> models owing to its use of `model__icontains`:
>
> {{{#!py
> ctypes = ContentType.objects.using(db).filter(
> app_label=self.app_label, model__icontains=old_model.lower()
> )
> for permission in Permission.objects.using(db).filter(
> content_type_id__in=ctypes.values("id")
> ):
> }}}
>
> To reproduce:
>
> - Have `Song` and `SongProfile` models, assign a view permission on
> `SongProfile` to a user
> - Rename `Song` to `Son`, migrate
> - `RenamePermission` adjusts the four permissions on each model (8 perms
> total) to all have "son" in the name & codename
> - Permissions are now missing for `SongProfile` , so they get regenerated
> by the post_migrate handler
> - existing user/group assignments (e.g. the one created above) are now
> pointing to the wrong permission ("add_son" with a content type pointing
> to `SongProfile`)
>
> Unlike #36793, which hinged on the existence of stale records causing
> conflicts (possibly from reapplying or reversing migrations in
> environments that had stale permissions before Django 6), this scenario
> doesn't involve any duplicates, and the models in step 2 don't need to be
> the same as step 1, just have common substrings. I reused a model for
> convenience, but the point is that an unrelated model's permissions are
> being affected.
>
> Suggesting to revert of f02b49d2f3bf84f5225de920ca510149f1f9f1da and that
> we address the issues identified in
> https://github.com/django/django/pull/20481 (which was a first pass at
> identifying & fixing) with more breathing room in a future version.
New description:
As of Django 6.0 (#27489), when a migration contains a `RenameModel`
operation, ephemeral `RenamePermission` operations are injected to sync
the name & codename of the model's permission records.
As mentioned in
https://github.com/django/django/pull/20339#discussion_r2653481704, we
discovered that the ephemeral operation might operate on unrelated models
owing to its use of `model__icontains`:
{{{#!py
ctypes = ContentType.objects.using(db).filter(
app_label=self.app_label, model__icontains=old_model.lower()
)
for permission in Permission.objects.using(db).filter(
content_type_id__in=ctypes.values("id")
):
}}}
To reproduce:
- Have `Song` and `SongProfile` models, migrate (this produces permission
records during `post_migrate`)
- assign a view permission on `SongProfile` to a user
- Rename `Song` to `Son`, migrate
- `RenamePermission` adjusts the four permissions on each model (8 perms
total) to all have "son" in the name & codename
- Permissions are now missing for `SongProfile` , so they get regenerated
by the post_migrate handler
- existing user/group assignments (e.g. the one created above) are now
pointing to the wrong permission ("add_son" with a content type pointing
to `SongProfile`)
Unlike #36793, which hinged on the existence of stale records causing
conflicts (possibly from reapplying or reversing migrations in
environments that had stale permissions before Django 6), this scenario
doesn't involve any duplicates, and the models in step 2 don't need to be
the same as step 1, just have common substrings. I reused a model for
convenience, but the point is that an unrelated model's permissions are
being affected.
Suggesting to revert of f02b49d2f3bf84f5225de920ca510149f1f9f1da and that
we address the issues identified in
https://github.com/django/django/pull/20481 (which was a first pass at
identifying & fixing) with more breathing room in a future version.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/36843#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019b8f845a49-08b36c4b-ce05-4400-be26-dad504b27569-000000%40eu-central-1.amazonses.com.
