Operand coercion breaks MappingProxyType encapsulation #88762

Activity

1. ncoghlan commented on Jul 10, 2021

   

   ncoghlan

   on Jul 10, 2021

   ContributorAuthor

   More actions

   The fast locals proxy implementation for PEP-558 used the existing MappingProxyType implementation as a starting point.

   This meant I noticed the following code in the mapping proxy comparison implementation:

   ======

   static PyObject *
   mappingproxy_richcompare(mappingproxyobject *v, PyObject *w, int op)
   {
       return PyObject_RichCompare(v->mapping, w, op);
   }

   ======

   Seeing that code lead to trying the following experiment:

   ==========

   >>> from types import MappingProxyType
   >>> d = {}
   >>> proxy = MappingProxyType(d)
   >>> class Sneaky:
   ...     def __eq__(self, other):
   ...         if other is d:
   ...             raise RuntimeError("Broke encapsulation")
   ... 
   >>> proxy == Sneaky()
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "<stdin>", line 4, in __eq__
   RuntimeError: Broke encapsulation

   ==========

   The new __or__ implementation has a corresponding loophole:

   ========

   >>> class SneakyOr:
   ...     def __or__(self, other):
   ...         if other is d:
   ...             raise RuntimeError("Broke encapsulation")
   ...     def __ror__(self, other):
   ...         return self.__or__(other)
   ... 
   >>> proxy | SneakyOr()
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "<stdin>", line 6, in __ror__
     File "<stdin>", line 4, in __or__
   RuntimeError: Broke encapsulation

   ========

   Delegating these operations to the underlying mapping via the abstract operation layer means that the underlying mapping gets exposed to the operand coercion machinery and can hence be accessed by the other operand.
2. ncoghlan

   added

   3.11only security fixesonly security fixes

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Jul 10, 2021
3. serhiy-storchaka commented on Jul 10, 2021

   

   serhiy-storchaka

   on Jul 10, 2021

   Member

   More actions

   It is a duplicate of bpo-43838.
4. serhiy-storchaka

   closed this as completedon Jul 10, 2021
5. serhiy-storchaka

   closed this as completedon Jul 10, 2021
6. ezio-melotti

   transferred this issue fromon Apr 10, 2022