With the new patch, the HUD is generating the correct value for its path, as
seen in this dbus apparmor denial:
Aug 31 17:08:33 localhost dbus[17542]: apparmor="DENIED"
operation="dbus_method_call" bus="session" name=":1.89"
path="/com/canonical/hud/applications/de_2edjfun_2eakari_5fAkari_5f0_2e1_2"
interface="com.canonical.hud.Application" member="SetWindowContext" mask="send"
pid=19084 profile="de.djfun.akari_Akari_0.1" peer_pid=17957
peer_profile="unconfined"
such that the following rule allows the application to communicate with the HUD:
@{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"
...
dbus (send)
bus=session
path=/com/canonical/hud/applications/@{APP_ID_DBUS}*,
This works well when starting the application with aa-exec-click and
upstart-app-launch (note, I had to modify dropping letters to use:
HUD.HUD { applicationIdentifier: "com.ubuntu.dropping-letters_dropping-
letters_0.1.2.2" ... } since it was not setting up its app id
correctly).
Unrelated to this bug, on unity 7 the appid is not properly set up and
the object path used by the application is
/com/canonical/hud/applications/unknown_1. This can be seen when
launching the application via the Dash.
--
You received this bug notification because you are a member of DX
Packages, which is subscribed to hud in Ubuntu.
https://bugs.launchpad.net/bugs/1218107
Title:
hud should use APP_ID and libnih to generate the DBus path
Status in “hud” package in Ubuntu:
Triaged
Status in “hud” source package in Saucy:
Triaged
Bug description:
We discussed DBus APIs in relation to application confinement in various
places and decided that services that require DBus mediation, click packaging
and apparmor should all agree on how to derive an application-specific DBus
path. The concept of the APP_ID is central to click, the SDK, application
lifecycle, apparmor and DBus services that applications use. The APP_ID is of
the form:
$pkgname_$appname_$version
and this is derived from the click manifest. Eg:
com.ubuntu.dropping-letters_dropping-letters_0.1.2.2
Application lifecycle will export the APP_ID to the environment. The
click-apparmor hook creates the @{APP_ID_DBUS} variable in apparmor policy for
use in dbus rules. click-apparmor uses nih_dbus_path() from libnih-dbus to
generate the @{APP_ID_DBUS}. Eg, for
com.ubuntu.dropping-letters_dropping-letters_0.1.2.2, we would have:
@{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"
This allows us to have rules like this in apparmor policy:
dbus (send)
bus=session
path="/com/canonical/hud/applications/@{APP_ID_DBUS}",
However, the HUD is generating a different value for its path, as seen in
this dbus apparmor denial:
dbus[3390]: apparmor="DENIED" operation="dbus_method_call" bus="session"
name=":1.641"
path="/com/canonical/hud/applications/com_ubuntu_dropping_letters_dropping_letters_0_1_2_2"
interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send"
pid=23875 profile="com.ubuntu.dropping-letters_dropping-letters_0.1.2.2"
peer_pid=22913 peer_profile="unconfined"
We need the hud and apparmor to agree, otherwise we have to use policy
that's much too lenient where malicious applications can interfere
with other apps. Please adjust the hud to use libnih-dbus. Attached is
a test C program to demonstrate how to do this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hud/+bug/1218107/+subscriptions
--
Mailing list: https://launchpad.net/~dx-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dx-packages
More help : https://help.launchpad.net/ListHelp
