ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

Public bug reported:

Currently it's possible to call BrowserContext::GetDelegate() on any
thread, but BrowserContextDelegate has methods whose implementations in
qt/ are just plain unsafe to call on anything other than the IO thread
(it looks like this applies to pretty much all of them).

I noticed this whilst looking at
https://code.launchpad.net/~justinmcp/oxide/pepper-flash/+merge/234058 -
it calls BrowserContextDelegate::CanAccessStorage on the UI thread,
which is not safe.

We should prevent usage of BrowserContextDelegate off the IO thread.

For an alternative to BrowserContextDelegate::CanAccessStorage on the UI
thread - this will depend on content settings as opposed to delegating
storage access checks to an embedder provided worker script on the IO
thread.

As an interim, we should make BrowserContextIOData::CanAccessCookies not
delegate to BrowserContextDelegate - this is sufficient for checking
whether a particular storage access attempt is ok, according to the
current cookie policy. However, it won't be possible to have more fine-
grained storage access checks off the IO thread until we content
settings.

** Affects: oxide
     Importance: Medium
         Status: Triaged

** Changed in: oxide
   Importance: Undecided => Medium

** Changed in: oxide
       Status: New => Triaged

** Description changed:

  Currently it's possible to call BrowserContext::GetDelegate() on any
  thread, but BrowserContextDelegate has methods whose implementations in
- qt/ or just plain unsafe to call on anything other than the IO thread
+ qt/ are just plain unsafe to call on anything other than the IO thread
  (it looks like this applies to pretty much all of them).
  
  I noticed this whilst looking at
  https://code.launchpad.net/~justinmcp/oxide/pepper-flash/+merge/234058 -
  it calls BrowserContextDelegate::CanAccessStorage on the UI thread,
  which is not safe.
  
  We should prevent usage of BrowserContextDelegate off the IO thread.
  
  For an alternative to BrowserContextDelegate::CanAccessStorage on the UI
  thread - this will depend on content settings as opposed to delegating
  storage access checks to an embedder provided worker script on the IO
  thread.

** Description changed:

  Currently it's possible to call BrowserContext::GetDelegate() on any
  thread, but BrowserContextDelegate has methods whose implementations in
  qt/ are just plain unsafe to call on anything other than the IO thread
  (it looks like this applies to pretty much all of them).
  
  I noticed this whilst looking at
  https://code.launchpad.net/~justinmcp/oxide/pepper-flash/+merge/234058 -
  it calls BrowserContextDelegate::CanAccessStorage on the UI thread,
  which is not safe.
  
  We should prevent usage of BrowserContextDelegate off the IO thread.
  
  For an alternative to BrowserContextDelegate::CanAccessStorage on the UI
  thread - this will depend on content settings as opposed to delegating
  storage access checks to an embedder provided worker script on the IO
  thread.
+ 
+ As an interim, we should make BrowserContextIOData::CanAccessCookies not
+ delegate to BrowserContextDelegate - this is sufficient for checking
+ whether a particular storage access attempt is ok, according to the
+ current cookie policy.

** Description changed:

  Currently it's possible to call BrowserContext::GetDelegate() on any
  thread, but BrowserContextDelegate has methods whose implementations in
  qt/ are just plain unsafe to call on anything other than the IO thread
  (it looks like this applies to pretty much all of them).
  
  I noticed this whilst looking at
  https://code.launchpad.net/~justinmcp/oxide/pepper-flash/+merge/234058 -
  it calls BrowserContextDelegate::CanAccessStorage on the UI thread,
  which is not safe.
  
  We should prevent usage of BrowserContextDelegate off the IO thread.
  
  For an alternative to BrowserContextDelegate::CanAccessStorage on the UI
  thread - this will depend on content settings as opposed to delegating
  storage access checks to an embedder provided worker script on the IO
  thread.
  
  As an interim, we should make BrowserContextIOData::CanAccessCookies not
  delegate to BrowserContextDelegate - this is sufficient for checking
  whether a particular storage access attempt is ok, according to the
- current cookie policy.
+ current cookie policy. However, it won't be possible to have more fine-
+ grained storage access checks off the IO thread until we content
+ settings.

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1470187

Title:
  Prevent access to BrowserContextDelegate off the IO thread

Status in Oxide Webview:
  Triaged

Bug description:
  Currently it's possible to call BrowserContext::GetDelegate() on any
  thread, but BrowserContextDelegate has methods whose implementations
  in qt/ are just plain unsafe to call on anything other than the IO
  thread (it looks like this applies to pretty much all of them).

  I noticed this whilst looking at
  https://code.launchpad.net/~justinmcp/oxide/pepper-flash/+merge/234058
  - it calls BrowserContextDelegate::CanAccessStorage on the UI thread,
  which is not safe.

  We should prevent usage of BrowserContextDelegate off the IO thread.

  For an alternative to BrowserContextDelegate::CanAccessStorage on the
  UI thread - this will depend on content settings as opposed to
  delegating storage access checks to an embedder provided worker script
  on the IO thread.

  As an interim, we should make BrowserContextIOData::CanAccessCookies
  not delegate to BrowserContextDelegate - this is sufficient for
  checking whether a particular storage access attempt is ok, according
  to the current cookie policy. However, it won't be possible to have
  more fine-grained storage access checks off the IO thread until we
  content settings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1470187/+subscriptions