On 2013/08/19 17:15:59, adamk wrote:
On 2013/08/19 10:19:59, rossberg wrote:
> On 2013/08/16 21:48:47, adamk wrote:
> > On 2013/08/16 13:51:54, rossberg wrote:
> > > This looks good so far, but unfortunately, I don't think it's
enough to
just
> > > check GET access. For example, HAS or KEYS might be restricted,
while
GET
is
> > > allowed.
> > >
> > > I think the accurate semantics would be something like this:
> > >
> > > - if an observer does not have GET access to a property, it should
not
see
> > > update changes for that property (but can still see delete or
> reconfiguration
> > > events);
> > >
> > > - if an observer does not have HAS access to a property, it should
not
see
> > > update, delete or reconfiguration changes for that property;
> > >
> > > - if an observer does not have KEYS access to an object, it should
not
see
> any
> > > changes for that object.
> > >
> > > Maybe it's not worth distinguishing the first and second, but you
still
need
> > to
> > > check for either access type. The last one applies to the whole
object,
as
> > > opposed to individual properties, which is something that we need to
> > distinguish
> > > in the tests.
> > >
> > > It's annoying that the API does not allow to ask about all access
types
in
> one
> > > call. But I don't see much we can do about that. Fortunately,
observe
> > > performance on access-checked objects should not matter in practice,
AFAICS.
> >
> > Thanks for mentioning ACCESS_KEYS. With that as a model, I think the
above
all
> > argues for just adding a new ACCESS_OBSERVE enum (as the one API
change)
and
> > following ACCESS_KEYS's lead of checking access via calling
MayNamedAccess()
> > with undefined as the "key" to check for whether observation is
allowed.
We
> > could check both at the time of initial observation and when
enqueueing.
> >
> > It simply doesn't seem worthwhile to allow observation of only some
changes
to
> > an object (which is what it seems you're proposing with the set of
complex
> rules
> > above), especially since in practice the only observed objects are
Window
and
> > Location, and moreover the only properties where access _is_ allowed
tend
to
> be
> > non-observable (they're provided by native accessors). Basically, if
you're
in
> a
> > place where an ACCESS_GET would fail, providing Object.observe doesn't
provide
> > value.
> >
> > What are your thoughts on that (minimal) change to the API?
>
> No, as we discussed before, this won't fly.
>
> It is not sufficient because we would still have to correctly deal with
the
> cases where ACCESS_OBSERVE was not filtered, but e.g. GET was -- which
includes
> all existing code in all embedders! The API allows these combinations
> (supposedly for a reason), so we haven't won anything by adding a new
flag,
we'd
> still need to check the other flags.
>
> It is not necessary, because if we properly check the other flags then
> ACCESS_OBSERVE would essentially be subsumed by ACCESS_KEYS. That is, we
don't
> provide any new useful functionality to users of the API.
>
> It is not an option anyway because requiring everybody to set and handle
> ACCESS_OBSERVE is a serious breaking change to the API at this point. It
breaks
> the security model of all existing embedders. And it probably breaks a
lot
of
> them functionally, because their access callbacks do not expect the new
value.
Do you know of any other embedders that use access checks, besides Blink?
I
would be surprised to learn that Node.js makes use of them. Basically I'm
asking: is this a theoretical concern (given that you don't know which
embedders
are out there) or is it concrete?
There are several browsers and browser-like environments besides Chrome that
embed either V8 or Blink+V8, e.g. Android, Opera, the tool chain Adobe is
working on, and some projects I know less about. And AFAIK even Blink
embedders
typically add their own additional native objects to the runtime on top of
what
Blink provides. So yes, AFAICT, this is a real issue. In particular, since
it is
easy to introduce security holes unnoticed with such a change.
Even if it wasn't, I still think the current access API is the correct
abstraction (or it least close to it). It filters by kind of observable
information and its possible modifications, not by what language operations
invoke those. That is an important abstraction, because you don't want to
make
the API and its uses dependent on the ever-changing zoo of operations the
language might provide. (Although admittedly it feels rather ES3 in its
current
form.)
Is there any use case you envision that would care whether observe is 10x vs
just 3x slower on objects with access checks?
https://codereview.chromium.org/22962009/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
