User talk:Comrade693/Storage Async API Security Review

Overview

This feature is intended to provide a way for consumers of storage to read and write from the database asynchronously so that blocking IO calls do not interfere with other work they are doing on the calling thread. In most cases, the calling thread is going to be the main thread, so not having blocking IO on the main thread means that we do not block the UI.

Background links

• bug 429986
• bug 458811
• Newsgroup discussion

Security and Privacy

• What security issues do you address in your project?
  • none that I am aware of
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • These new features do not depend on preferences.
  • These features could do bad things if SQLite was not compiled with SQLITE_THREADSAFE
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • We assume that all calling code is either going through XPConnect, or is native code that has access to libxul.
• How are transitions in/out of Private Browsing mode handled?
  • Consumers of storage would have to manage that themselves.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • mozIStorageError - represents an error returned
  • mozIStoragePendingStatement - gives a handle to the async statement allowing a consumer to cancel the execution
  • mozIStorageResultSet - container for a series of mozIStorageRows given to the callback
  • mozIStorageRow - holds the data returned from a row obtained from the execution of the async statement
  • mozIStorageStatementCallback - An optional listener that will be notified of results, errors, and completion of the execution of the async statement
• Does it interoperate with a web service? How will it do so?
  • no
• Explain the significant file formats, names, syntax, and semantics.
  • SQLite binary files (third party library)
• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
  • In the IDL, I hope so (it's hard to judge that being a Mozilla developer). Documentation on devmo is a little weak.
• Does it change any existing interfaces?
  • mozIStorageConnection - added an executeAsync method that takes an array of mozIStorageStatements and an optional mozIStorageStatementCallback
  • mozIStorageStatement - added an executeAsync method that takes an optional mozIStorageStatementCallback

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)

Data

• What data is read or parsed by this feature
• What is the output of this feature
• What storage formats are used

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

Are there related projects in the community?

• no