Ubuntu

SDK: Application Data Folders

Registered by Cris Dywan on 2013-07-31

Applications running under confinement don't have access to $HOME or $XDG_ locations freely as on the classic desktop. Most locations are ready-only or mediated by a service.

Blueprint information

Status:: Not started

Approver:: Zoltan Balogh

Priority:: Undefined

Drafter:: Cris Dywan

Direction:: Approved

Assignee:: Cris Dywan

Definition:: Drafting

Series goal:: Accepted for saucy

Implementation:: Unknown

Milestone target:: None

Related branches

lp:~kalikiana/ubuntu-ui-toolkit/appname

Related bugs

Bug #1197047: SDK applications create /tmp/*.sci files	Fix Released
Bug #1197049: SDK applications sometimes create /var/tmp/etilqs_* files	Fix Released
Bug #1197051: SDK applications should not use ~/.local/share/Qt Project for sqlite files	Fix Released
Bug #1197056: SDK and cordova webview applications should not use ~/.local/share/*/.QtWebKit/ for their databases	Fix Released
Bug #1197060: SDK webview applications should use an app-specific path for shared memory files	Won't Fix
Bug #1206935: Default relative database filename to a sensible location	Fix Released
Bug #1224126: qtdeclarative5-u1db1.0 should not use ~/.local/share/Qt Project for db files	Fix Released
Bug #1231863: Local Sqlite databases are still created/stored in incorrect location	Fix Released
Bug #1233071: Set up the translation domain automatically for click packages	Fix Released
Bug #1234544: Several apps have failing tests with 20131003 ui-toolkit	Fix Released

Sprints

Whiteboard

Use cases:
U1Db. Databases belong into "share".
Proposed solution: default relative paths to the right location.

C++ QML plugin code. May need either "share" or "cache".
Needs API functions to access files.

QtWebKit
When WebKit is used, files are automatically written to "share".

localStorage
Using localStorage API may use "share" and "cache" (currently /var/tmp/).

Standard Qt5 API that works on the desktop today:
QStandardPaths::writableLocation(QStandardPaths::DataLocation)

Translations
On the desktop gettext reads .mo files containing translations from /usr/share/locale. On click packages it might make sense to read them from /opt/click.ubuntu.com/*$APP_PATH*/locale

Questions:
    Which locations can we support with and without confinement?
    ~/.local/share/$APP_ID
    ~/.cache/$APP_ID
    The $APP_ID used here is a placeholder that preferrably isn't exposed in API.

Do pure QML apps need access to absolute locations?
Unlikely. By design most QML API doesn't expose raw file access.

What about Firefox, LibreOffice and friends?
It's not clear if they will run under confinement - if they do, this only affects where internal data is stored, none of the GUI facing locations. That needs to be sorted separately.

Should XDG variables be overridden to enforce confined paths?
This should be seen as a last resort and preferrably avoided. Applications can be run in different ways and under different environments ie. Unity, KDE, Elementary etc and even if variables could be overriden per application it would result in complicated paths.

Resources:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement#Application_environment
https://bugreports.qt-project.org/browse/QTBUG-16549

(?)

Work Items

Work items for ubuntu-13.10:
[kalikiana] Collect use cases for app data storage: DONE
[kalikiana] Ensure U1Db-Qt uses a sensible storage folder: DONE
[kalikiana] Implement app-specific environment variables in confinement: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information

Everyone can see this information.

Subscribers

No subscribers.