oxide accesses gsettings, but shouldn't
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Oxide |
Triaged
|
High
|
Unassigned | ||
apparmor-easyprof-ubuntu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Without the following dconf rules, there are apparmor denials when using Oxide:
owner /run/user/
owner @{HOME}
gsettings is not supported in the SDK at this team and access to dconf is not allowed. Oxide appear to work ok without these rules, but the logs are noisy and will almost certainly lead to confusion.
It is conjectured that this is for proxy settings. Indeed, stderr shows this:
[1211/162140:
We could silence the apparmor denials, but it is possible that we will support gsettings some day and more importantly, silencing these denials will make it difficult for people writing apps to diagnose that they shouldn't be using gsettings.
Related branches
description: | updated |
tags: | added: application-confinement |
Changed in oxide: | |
importance: | Undecided → High |
Changed in oxide: | |
status: | New → Triaged |
This bug was fixed in the package apparmor- easyprof- ubuntu - 1.2.33
--------------- easyprof- ubuntu (1.2.33) utopic; urgency=medium
apparmor-
* ubuntu/accounts: allow access to GetAll on org.freedesktop .DBus.Propertie s code/AccountsSS O/SingleSignOn (LP: #1377205) etc/dconf_ profile. This is ubuntu- {sdk,webapp} : also allow talking to clipboard on freedesktop
for /com/google/
* ubuntu/webview: also deny access to /custom/
fallout from Oxide trying to use gsettings, but we've been silently
denying that access since the webview policy group was added, so just
silence this denial too (LP: #1260101)
* ubuntu/
interface (LP: #1377221)
* tests/test-data.py: update hardware dir handling and also adjust policy
groups to use tmpdir
* debian/control: Build-Depends on apparmor so we can check syntax during
builds
-- Jamie Strandboge <email address hidden> Fri, 03 Oct 2014 10:21:33 -0500