SDK applications should not use ~/.local/share/Qt Project for sqlite files

Bug #1197051 reported by Jamie Strandboge
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Fix Released
Undecided
Unassigned
apparmor-easyprof-ubuntu (Ubuntu)
Fix Released
Undecided
Unassigned
Saucy
Fix Released
Undecided
Unassigned
qtdeclarative-opensource-src (Ubuntu)
Invalid
High
Cris Dywan
Saucy
Invalid
High
Cris Dywan
ubuntu-ui-toolkit (Ubuntu)
Fix Released
Undecided
Unassigned
Saucy
Fix Released
Undecided
Unassigned

Bug Description

Ubuntu SDK applications store their sqlite data in locations like this:
~/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.ini
~/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.sqlite

This results in AppArmor rules like the following:
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/" rw,
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/" rw,
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/" rw,
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/Databases/" rw,
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.ini{,.*}" rwk,
owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.sqlite" rwk,

But these rules are too lenient and these paths need to be made application specific. Specifically: $XDG_DATA_HOME/<app pkgname> where '<app pkgname>' is the "name" field in the Click manifest (see bug #1197037 for details).

Related branches

tags: added: application-confinement
description: updated
Revision history for this message
David Planella (dpm) wrote : Re: [Bug 1197051] [NEW] SDK applications should not use ~/.local/share/Qt Project for sqlite files
Download full text (4.8 KiB)

Thinking about how core apps make use of the LocalStorage QML plugin to
store settings, this bug might easily be solved in some of them when we
migrate to using the GSettings QML backend (lp:gsettings-qt) to store the
settings.

However, it will not cover all cases, as there are genuine use cases for
using a database (such as storing past calculations in the calculator app)

Cheers,
David.

On Tue, Jul 2, 2013 at 7:17 PM, Jamie Strandboge <email address hidden> wrote:

> Public bug reported:
>
> Ubuntu SDK applications store their sqlite data in locations like this:
> ~/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.ini
> ~/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.sqlite
>
> This results in AppArmor rules like the following:
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/" rw,
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/" rw,
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/" rw,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/" rw,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.ini{,.*}" rwk,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.sqlite" rwk,
>
> But these rules are too lenient and these paths need to be made
> application specific. Specifically: $XDG_DATA_DIR/<app id> where '<app
> id>' will ultimately be the reverse domain name with Click packages (see
> bug #1197037 for details on '<app id>').
>
> ** Affects: ubuntu-qtcreator-plugins
> Importance: Undecided
> Status: New
>
> ** Affects: apparmor-easyprof-ubuntu (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: application-confinement
>
> ** Also affects: apparmor-easyprof-ubuntu (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Tags added: application-confinement
>
> ** Description changed:
>
> - Ubuntu SDK applications still their sqlite data in locations like this:
> + Ubuntu SDK applications store their sqlite data in locations like this:
> ~/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.ini
> ~/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/7dbf3433d69b4304a43526d9eca5b650.sqlite
>
> This results in AppArmor rules like the following:
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/" rw,
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/" rw,
> owner "@{HOME}/.local/share/Qt Project/QtQmlViewer/QML/OfflineStorage/"
> rw,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/" rw,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.ini{,.*}" rwk,
> owner "@{HOME}/.local/share/Qt
> Project/QtQmlViewer/QML/OfflineStorage/Databases/[0-9a-f]*.sqlite" rwk,
>
> But these rules are too lenient and these paths need to be made
> application specific. Specifically: $XDG_DATA_DIR/<app id> where '<app
> id>' will ultimately be the reverse domain name with Click packages (see
> bug...

Read more...

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Gsettings brings a similar set of problems because gsettings is a shared database and it would have to be updated somehow to make sure apps couldn't access each other's data. There is a blueprint for it: https://blueprints.launchpad.net/ubuntu/+spec/security-r-app-gsettings, but the (not insignificant) work is not currently scheduled for saucy because SDK apps are using their own sqlite files.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

And, like you said, there are legitimate cases for using an sqlite backend so the path issue needs to be solved anyway.

Changed in ubuntu-qtcreator-plugins:
assignee: nobody → Timo Jyrinki (timo-jyrinki)
affects: ubuntu-qtcreator-plugins → ubuntu-ui-toolkit
description: updated
Revision history for this message
Zoltan Balogh (bzoltan) wrote :

Changing the XDG_DATA_HOME variable in the runtime environment would change the target of these data files.

I was exporting the XDG_DATA_HOME=/tmp and launched the calculator app.

$ ls -l /proc/`ps aux | grep calculator|awk '{print $2}'|head -1`/fd|grep OfflineStorage

command shows the path unseting the XDG_DATA_HOME will change that.

Changed in ubuntu-ui-toolkit:
assignee: Timo Jyrinki (timo-jyrinki) → nobody
Changed in qtdeclarative-opensource-src (Ubuntu):
assignee: nobody → Christian Dywan (kalikiana)
Changed in apparmor-easyprof-ubuntu (Ubuntu Saucy):
status: New → Triaged
Changed in qtdeclarative-opensource-src (Ubuntu Saucy):
importance: Undecided → Critical
importance: Critical → High
description: updated
Revision history for this message
Ken VanDine (ken-vandine) wrote :

Are there any details on how this will be resolved? I've hit this with the Store implementation in content-hub. I need to be able to get a path that is allowed by apparmor for transferring content. For example, I'd like to be able to use QStandardPaths::writableLocation(QStandardPaths::CacheLocation) and get a path like @{HOME}/.cache/@{APP_PKGNAME}/

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ken, this bug doesn't directly affect the content-hub. The apparmor profile currently gives you access to @{HOME}/.cache/@{APP_PKGNAME}/. This bug is about the workaround policy that is also in place for @{HOME}/.local/share/Qt Project/QtQmlViewer/... that we need to get rid of. Since content-bub gives back URL to the app, use QStandardPaths like you suggested and give that URL to the app and it should all work fine.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

Jamie, the problem is QStandardPaths::CacheLocation returns @{HOME}/.cache/Qt Project/QtQmlViewer. It looks like the branch proposed for ubuntu-ui-toolkit will solve this.

It would be nice if there was an API for getting APP_PKGNAME and other attributes that are defined in click packages. I've been having to jump through hoops to get that kind of information, even calling the GetConnectionAppArmorSecurityContext over dbus to get the profile name. Perhaps the SDK could expose these useful variables?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Regarding @{HOME}/.cache/Qt Project/QtQmlViewer, yes that is a bug that like you said, should solve this.

As for an API to find APP_PKGNAME, apps themselves can do it by accessing applicationName presumably or some other method that the developer can choose.

Correct me if I'm wrong, but I think your question is more about services for apps, like the content-hub. This is all very service specific, but in general you cannot trust what the application gives you and the only thing you can trust is the security label for the process which you can get via a libapparmor C call or over DBus (as mentioned). This label provides you with the profile name, which on Ubuntu will is the APP_ID for confined processes that come from click packages. While I think it might be a useful improvement to have some sort of a click library that could be used to give various information, we *must* always use the security label from the kernel if there are any security implications or decisions (like where to read or write a file).

Also keep in mind going forward, there are non-click confined processes and there are also unconfined processes which both become more relevant on the converged device. Unity8 will have the concept of APP_ID because of application lifecycle, but other desktop environments will not (perhaps that will be ported to Unity7). There is work to be done in this area.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

The branch proposed for ubuntu-ui-toolkit provides me a pretty good solution for what I need. Accessing applicationName is really what I need. For content-hub, the APP_ID from the client is included in the transfer request, done automatically in the hub client API. Right now it does that by getting APP_ID environment variable. Perhaps I should default to using applicationName and fall back to APP_ID from the environment if it isn't set?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Spoke a bit about this on IRC. The app requesting content can just use applicationName-- it shouldn't have to fiddle around with the environment. This is safe for click apps because if they somehow changed the application name, they are still limited by AppArmor mediation of the underlying DBus API.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:ubuntu-ui-toolkit at revision None, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

Changed in ubuntu-ui-toolkit:
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-ui-toolkit - 0.1.46+13.10.20130925.1-0ubuntu1

---------------
ubuntu-ui-toolkit (0.1.46+13.10.20130925.1-0ubuntu1) saucy; urgency=low

  [ Timo Jyrinki ]
  * Temporarily disable the jokes example in order to not have
    qtmultimedia dependency from examples that is not used otherwise.
    This lessens the dependency chains of packages. It can be added back
    after Ubuntu 13.10.
  * Fix regression in qmlscene usage (LP: #1229541). (LP: #1229541)

  [ Christian Dywan ]
  * Set QCoreApplication::applicationName based on MainView. (LP:
    #1197056, #1197051, #1224126)
  * Include subfolders of Components in api check.

  [ Zsombor Egri ]
  * Organizer EDS (Evolution Data Server) integration.
  * StateSaver attached component.
  * Fix alarm status reporting, updating documentation on asynchronous
    behavior of save and cancel operations. Alarm status notification
    reports the operation the status refers to. (LP: #1226516)
  * Dialer + DialerHand components required for TimePicker. .

  [ Leo Arias ]
  * Added UbuntuUIToolkitAppTestCase as a base test case for the
    autopilot tests. (LP: #1227355)
  * Added the autopilot emulator for toggles.

  [ Nick Dedekind ]
  * Added clipping to tab bar. (LP: #1226104)

  [ Alberto Mardegan ]
  * Support re-attaching to a different QQuickView Make the plugin
    correctly handle the case when the QQuickView is destroyed and a new
    one is created: this is done by avoiding using static variables, and
    instead binding the data to the QQmlEngine, QQmlContext or QWindow
    as appropriate. . (LP: #1221707)

  [ Dennis O'Flaherty ]
  * Reword the description for easier reading.

  [ tpeeters ]
  * Fix warnings when running gallery-app autopilot tests. (LP:
    #1223329, #1223326)
  * Smarter automatic updating of Panel's opened property. Panel.open()
    and Panel.close() should be used to open/close a Panel, or when
    using a toolbar with ToolbarItems from a Page, set Page.tools.opened
    to open/close the toolbar. No API or behavior changes since the
    panel-open-close branch. Toolbar behavior changes will be done in a
    following MR.

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 765
 -- Ubuntu daily release <email address hidden> Wed, 25 Sep 2013 07:08:56 +0000

Changed in ubuntu-ui-toolkit (Ubuntu Saucy):
status: New → Fix Released
Changed in ubuntu-ui-toolkit:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.0.35

---------------
apparmor-easyprof-ubuntu (1.0.35) saucy; urgency=low

  * apparmor-easyprof-ubuntu.install: install data/hardware/*, thus allowing
    porters, OEMs, etc to ship their own policy without having to modify this
    package (LP: #1197133)
  * add data/hardware/graphics.d/* and data/hardware/audio.d/*, namespaced to
    this package. We will move these out to lxc-android-config later
  * tests/test-data.py: adjust to test data/hardware/*
  * accounts: move to reserved status until LP: 1230091 is fixed
  * calendar: remove workaround rule for gio DBus path (LP: #1227295)
  * add usermetrics policy group so apps can update the infographic
  * ubuntu-* templates:
    - allow StartServiceByName on the system bus too. This is needed by the
      new usermetrics policy group and we will presumably have more going
      forward (eg location)
    - account for /org/freedesktop/dbus object path. This seems to be used by
      the python DBus bindings (eg, friends)
    - move hardware specific accesses out of the templates into
      hardware/graphics.d/ in preparation of the move to shipping these in
      lxc-android-config (note, this doesn't change apparmor policy in any
      way)
    - add 'r' to dbus system bus socket (LP: #1208988)
    - add ixr access to thumbnailer helper (LP: #1234543)
    - finetune HUD access
    - don't use ibus abstraction but instead use 'r' access for
      owner @{HOME}/.config/ibus/**
    - don't use freedesktop.org abstraction but instead add read accesses
      for /usr/share/icons and various mime files
    - updates for new gstreamer
      - move in gstreamer accesses from audio policy groupd due to hybris
  * ubuntu-sdk template:
    - remove workaround paths now that ubuntu-ui-toolkit is using
      QCoreApplication::applicationName based on MainView's applicationName
      (LP: #1197056, #1197051, #1224126, LP: #1231863)
  * ubuntu-webapp template:
    - allow read access to /usr/share/unity-webapps/userscripts/**
    - allow rix to gst-plugin-scanner
  * add reserved friends policy group (reserved because it needs integration
    with trust-store to be used by untrusted apps)
  * remove peer from receive DBus rules in the ubuntu-* templates and the
    contacts, history, and location policy groups (LP: #1233895)
  * audio:
    - move gstreamer stuff out to templates since hybris pulls it in for all
      apps
    - include hardware/audio.d for hardware specific accesses
 -- Jamie Strandboge <email address hidden> Mon, 07 Oct 2013 13:18:27 -0500

Changed in apparmor-easyprof-ubuntu (Ubuntu Saucy):
status: Triaged → Fix Released
Changed in qtdeclarative-opensource-src (Ubuntu Saucy):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.