User talk:Comrade693/Storage Async API Security Review
From MozillaWiki
Contents
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
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)
- None added with this change
- Existing REQUIRES
- xpcom
- string
- sqlite3
- js
- xpconnect
- necko
Data
- What data is read or parsed by this feature
- SQLite handles this
- What is the output of this feature
- Data results read from the database via SQLite to consumers
- Data written to disk by SQLite
- What storage formats are used
- SQLite binary files
Reliability
- What failure modes or decision points are presented to the user?
- None to the user
- The consumer is notified of results, errors, and completion. Additionally, it can cancel the execution of the statement at any time.
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
- Files should not be corrupted by failures. SQLite manages the cleanup 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
