UbuntuOne Architecture

u1 has two locations for databases: local and remote. Local data and remote data are kept in sync.

Remote u1 databases are in the u1 servers. Apps wanting access to a remote db must get a token from online accounts[1].

Local u1 databases are stored in sqlite files and accessed in process via libraries. Apps may have their own per-app u1db, and these are/will be stored in ~/.local/share/app-id, such that app 'foo' can read/write ~/.local/share/foo/<sqlitedb> and app 'bar can read/write ~/.local/share/bar/<sqlitedb>, but foo cannot access bar's u1db or vice versa. Some u1 databases might be shared, such as 'Contacts'. Access to shared u1dbs must be coordinated via another process for concurrency

Application confinement

Remote

Because remote u1 database access requires a token and because this token is managed via online accounts[2], everything works as expected. Ie:

• security manifest file specifies the 'accounts' policy group, which allows
  • DBus access to online accounts dbus service
• when app wants access to a remote u1db, it asks online accounts for the
  • token for a particular u1db. online accounts prompts user and caches the result. If user granted access, token is given to app

Local per-app databases

Per-app u1db is currently handled by application confinement, because the sqlite databases are stored in @{HOME}/.local/share/app-id, and we have the following in the ubuntu-sdk template:

• owner @{HOME}/.cache/@{APPNAME}/ rw, owner @{HOME}/.cache/@{APPNAME}/** mrwkl, owner @{HOME}/.local/share/@{APPNAME}/ rw, owner @{HOME}/.local/share/@{APPNAME}/** mrwklix,

== Local shared databases === Shared u1dbs, like contacts, are currently not handled by application confinement. Specifically, access to the shared database files are blocked. An out of process helper needs to be in place to handle concurrency anyway, and this helper should become a trusted helper. Apps will continue to not have file access to the shared databases and should access the data via a trusted helper DBus service (the apps themselves can of course use a library to simplify this). This trusted helper might then act like online accounts. Specifically:

• a policy group would be specified for each trusted helper (eg, 'contacts'
  • or 'calendar')
• if 'contacts' is specified in foo's security manifest, when foo tries to
  • access the contacts trusted helper over DBus, the contacts trusted helper prompts the user for the access (and may optionally cache the result)

This concept is already understood-- apps aren't expected to access the local data files directly and are expected to use a higher level API to have access to the data (this is needed for concurrency). The fact that the data is backed by u1 is hidden from the app. Eg, AIUI, the design for Contacts already uses an out of process helper for apps to communicate with and get data from and this helper will provide a meaningful contextual prompt to the user when an app wants access to the data.