[Harmony Proxies] Proposal: Property fixing
david.bruant at labri.fr
Thu Jun 16 07:00:50 PDT 2011
Le 16/06/2011 00:53, Mark S. Miller a écrit :
> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
> In a way, the fixed properties proposal make proxies bicephal. For
> inputs (property names), they plug their handler-provided
> MOP-brain and
> for some others, they plug a native object MOP-brain (ES5 - 8.12).
> brains cannot communicate. This is why changing .length in the "native
> object brain" has no effect in the other brain (which handles numeric
> properties(...unless some of these are non-configurable)). And I think
> it has been said before, but there would be no logging possible for
> non-configurable properties in the context of the fixed properties
> strawman since native MOP-brain doesn't allow that.
> Cute metaphor. But as Tom's code showed, the proxy can create fixed
> (non-configurable) accessor properties whose getters and setters form
> a corpus callosum ;).
I think I see also a potential security issue. In Tom's code, getters
and setters of the non-configurable properties trigger code of what was
in the handler. This is useful as a user to keep triggering the get and
set traps, but it also leaks a reference to these functions (after a
call to Object.getOwnPropertyDescriptor). In the current proposal,
before a property becomes non-configurable, there is no access to any
trap (unless having access to the object which implies having indirect
access to all traps or the handler itself). After becoming a
non-configurable accessor property, the get and set trap applied to the
non-configurable properties become available as independant functions
that can be passed around.
Currently, one can revoke the access to an object with a
membrane/wrapper, but with the leak, I think that all getter/setters
will have to be wrapped as well (their call trap in particular)? Ok,
maybe there is no security issue, but it adds a little bit more work.
I was first enthousiastic by the general idea of keeping get/set traps
through getter/setters (came up first with the fix trap, I think), but
since there is an API allowing to extract these functions independently,
I'm not really sure it's a good idea (in general) anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss