| 2014-02-11 14:05:08 |
Jamie Strandboge |
description |
Online Accounts can be extended with new account providers and services provided in click packages. A click hook will install these files in the correct place under ~/.local/share/accounts/{provider,services}/ .
Indeed, click applications should be able to use the account they install, so they need read access to these directories (the "accounts" apparmor template already gives access to the system locations: "/usr/share/accounts/** r,"). Therefore, I'd like to suggest adding the following line to the apparmor "accounts" template:
@{HOME}/.local/share/accounts/** r,
(I tested my click application with this line added, and it solved the problem)
Ideally, though, we would like that these files were readable only by those applications which installed them: that is, if a click package ships an application and an Online Account service, we'd like only this application to be able to access the file. Given that these files are installed under ~/.local/share/accounts/ as symlinks, I was expecting that apparmor would check the access also on the symlink target file, but that doesn't seem to be the case.
This is not a critical issue, but if you can think of some way to achieve what we want, that'd be super. :-) |
Online Accounts can be extended with new account providers and services provided in click packages. A click hook will install these files in the correct place under ~/.local/share/accounts/{provider,services}/ .
Indeed, click applications should be able to use the account they install, so they need read access to these directories (the "accounts" apparmor template already gives access to the system locations: "/usr/share/accounts/** r,"). Therefore, I'd like to suggest adding the following line to the apparmor "accounts" template:
owner @{HOME}/.local/share/accounts/** r,
Given that these files are installed under ~/.local/share/accounts/ as symlinks, this means that apps will dereference the symlinks in this directory to access their own accounts provider (which is in an app-specific directory). This is not an information leak on its own because users of this policy group have read access to accounts.db. |
|
