a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 11 18:07:13 PDT 2013


OK, this won't work Function('m','return m()')(method) ... but I wondr if
the key is there, in anonymous functions, that could be specced being
anonymous, won't be leak caller and arguments or anything ... no idea, but
I think the solution could be different, imho.


On Mon, Mar 11, 2013 at 5:56 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> if I do not return that function explicitly and since I own that function
> being the one that put a `caller` inside it where is exactly the problem
> ... once again?
>
> I would agree 100% if there was a global way to retrieve the currently
> invoked function but caller, is even more secure than call, apply, and
> bind, 'cause it cannot be overwritten in a meaningful way ( ok, it could
> probably deleting the descriptor and putting it back later on )
>
> If I've passed that object I could also argue that object should not be
> modified until I decide. There's no mechanism to drop a temporarily frozen
> state because I've sent the object I trust to another function.
>
> Moreover, if I created the function that uses .caller is because I own
> that function and I put it publicly accessible and maybe I want to know
> who's invoking it and how ... is like baking a pie asking you to let me
> know when you want to eat it because you know what ? maybe I can throw if
> the action is eat() instead of throw() when the context expiration date is
> expired, you know what I mean? I've created that bloody pie, who better
> than me can decide or suggest when and how to use it?
>
> If you call unknown functions inside your code, the fact there is a caller
> is actually the last problem you might have, isn't it?
>
> Also, if that is the **real** problem, you can maybe just
> Function('m','return m()')(method) so that caller would be null, right ?
>
> But I understand there's no way caller is gonna be back, even if reasons
> aren't in my opinion, valid enough.
>
> br
>
>
>
> On Mon, Mar 11, 2013 at 5:10 PM, Dean Landolt <dean at deanlandolt.com>wrote:
>
>>
>> On Mon, Mar 11, 2013 at 7:57 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt <dean at deanlandolt.com>wrote:
>>>
>>>> it's not the same thing as apply, bind, or call -- in each of the
>>>> latter forms you're explicitly handing out the `this` reference capability.
>>>> There's clearly no capability leak as with caller.
>>>>
>>>
>>> I wonder how would you access the `this` reference using `caller` from
>>> somewhere else, exactly, 'cause more I think about above sentence, the more
>>> I realize I really do not understand what are you talking about ...
>>>
>>> (function test() {
>>>   function what() {
>>>     alert(what.caller);
>>>   }
>>>   what();
>>> }());
>>>
>>> So I've got `test` there, now what about leaking `this` ... how ?
>>>
>>
>> The leakage is that caller is a reference -- having that reference gives
>> you the *capability *to follow any further references on its object
>> graph. This reference wasn't explicitly handed out (as is always the case
>> with this-binding in call, apply and bind) -- it was just *leaked* out
>> by the simple fact that the function was called. It's very possible the
>> caller has all kinds of powers you didn't intend to expose to the callee --
>> these powers have been leaked. It's really not complex -- this is an
>> inherent, unpluggable leak. And since OCap is now *the* security model
>> of es, there really no sense in trying to revive caller -- it's gone for
>> good.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/2dc23dfc/attachment-0001.html>


More information about the es-discuss mailing list