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 < [email protected]> 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 <[email protected]>wrote: > >> >> On Mon, Mar 11, 2013 at 7:57 PM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt <[email protected]>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. >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
