2.2.8.txt 2.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162
  1. ==========================
  2. Django 2.2.8 release notes
  3. ==========================
  4. *December 2, 2019*
  5. Django 2.2.8 fixes a security issue, several bugs in 2.2.7, and adds
  6. compatibility with Python 3.8.
  7. CVE-2019-19118: Privilege escalation in the Django admin.
  8. =========================================================
  9. Since Django 2.1, a Django model admin displaying a parent model with related
  10. model inlines, where the user has view-only permissions to a parent model but
  11. edit permissions to the inline model, would display a read-only view of the
  12. parent model but editable forms for the inline.
  13. Submitting these forms would not allow direct edits to the parent model, but
  14. would trigger the parent model's ``save()`` method, and cause pre and post-save
  15. signal handlers to be invoked. This is a privilege escalation as a user who
  16. lacks permission to edit a model should not be able to trigger its save-related
  17. signals.
  18. To resolve this issue, the permission handling code of the Django admin
  19. interface has been changed. Now, if a user has only the "view" permission for a
  20. parent model, the entire displayed form will not be editable, even if the user
  21. has permission to edit models included in inlines.
  22. This is a backwards-incompatible change, and the Django security team is aware
  23. that some users of Django were depending on the ability to allow editing of
  24. inlines in the admin form of an otherwise view-only parent model.
  25. Given the complexity of the Django admin, and in-particular the permissions
  26. related checks, it is the view of the Django security team that this change was
  27. necessary: that it is not currently feasible to maintain the existing behavior
  28. while escaping the potential privilege escalation in a way that would avoid a
  29. recurrence of similar issues in the future, and that would be compatible with
  30. Django's *safe by default* philosophy.
  31. For the time being, developers whose applications are affected by this change
  32. should replace the use of inlines in read-only parents with custom forms and
  33. views that explicitly implement the desired functionality. In the longer term,
  34. adding a documented, supported, and properly-tested mechanism for
  35. partially-editable multi-model forms to the admin interface may occur in Django
  36. itself.
  37. Bugfixes
  38. ========
  39. * Fixed a data loss possibility in the admin changelist view when a custom
  40. :ref:`formset's prefix <formset-prefix>` contains regular expression special
  41. characters, e.g. ``'$'`` (:ticket:`31031`).
  42. * Fixed a regression in Django 2.2.1 that caused a crash when migrating
  43. permissions for proxy models with a multiple database setup if the
  44. ``default`` entry was empty (:ticket:`31021`).
  45. * Fixed a data loss possibility in the
  46. :meth:`~django.db.models.query.QuerySet.select_for_update()`. When using
  47. ``'self'`` in the ``of`` argument with :ref:`multi-table inheritance
  48. <multi-table-inheritance>`, a parent model was locked instead of the
  49. queryset's model (:ticket:`30953`).