Hi all, am hoping for some help with a couple confinement issues I am having with indicator-sensors - currently I am getting it to build successfully and it runs but it can’t lookup sensor readings from libsensors due to being unable to access /etc/sensors3.conf and it can’t access udisks2 over dbus due to apparmor blocking:
Error: File /etc/sensors3.conf: Permission denied
[udisks2] DEBUG: Error getting udisks2 client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.145" (uid=1000 pid=8256 comm="indicator-sensors -vv " label="snap.indicator-sensors.indicator-sensors (enforce)") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=1082 comm="/usr/lib/udisks2/udisksd " label="unconfined")
Any ideas about how to get access to udisks2 over dbus? I notice udisks2 is listed as an interface on https://docs.snapcraft.io/reference/interfaces but when I run snap interfaces this is not listed and it doesn’t seem to be working for me.
The opt-in needs to be done by all users but we will move layouts out of beta soon (perhaps in 2.35). It is a temporary measure because the code is new and we wanted to ensure people have the best experience.
As for udisks, let me look, it should be available for use (though you will need a store assertion to auto-connect to it).
Snapd differentiates classic systems such as Fedora, Ubuntu, openSUSE or Debian and core systems. Core systems are typically embedded products that don’t use classic packages (like rpm or deb) at all and instead are entirely made out of snap packages.
While @zyga-snapd’s suggestion will let your snap continue to function, it won’t let you see the sensors.conf that is on the system (the layout feature let’s you say something like “put this file in my $SNAP directory in /etc”). Your indicator actually needs to access the real /etc/sensors3.conf. This should be part of the hardware-observe interface. I’ll take a TODO for that.
@jdstrand - thanks - so is the general design for confinement of snaps on classic systems to provide snapd etc with all the knowledge of the various system services in the base system? ie. in this case it is udisks, there are likely many other system services that snaps may want to access - do we add interfaces for them all?
Sort of. Sometimes snapd only needs to say, know about a device such as /dev/tpm0 and not the protocol used to communicate with the device. Other times a DBus service might provide an API that we want to mediate in some way (eg, part of the API, like with location-service) or just simply give access to (eg, like with udisks2).
In general, we add interfaces for the resources and services that matter to snap publishers, so while we don’t have an interface for everything, we have a lot (see snap interfaces to see what is available on your system).
Thanks for your help - so I was initially concerned that /etc/sensors3.conf would not exist for most users in the base install - but in this case libsensors4 (the package which provides /etc/sensors3.conf) seems to be pretty tightly ingrained in the standard desktop install:
$ sudo apt purge libsensors4
[sudo] password for amurray:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
gnome-shell : Depends: libmutter-2-0 (>= 3.27.91) but it is not going to be installed
Depends: gir1.2-mutter-2 (>= 3.27.91) but it is not going to be installed
Depends: mutter (>= 3.27.91) but it is not going to be installed
Recommends: gnome-control-center but it is not going to be installed
Recommends: gnome-user-guide but it is not going to be installed
Recommends: ubuntu-session but it is not going to be installed or
gnome-session but it is not going to be installed
gvfs-daemons : Depends: x11-utils
libgtk-3-dev : Depends: libegl1-mesa-dev but it is not going to be installed
ubuntu-release-upgrader-gtk : Depends: gir1.2-webkit2-4.0 but it is not going to be installed
xserver-xorg-input-all : Depends: xserver-xorg-input-libinput but it is not going to be installed
Recommends: xserver-xorg-input-wacom but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
So that seems fine - so in general is there a rule / guide when adding exceptions to the apparmor profiles etc as to what could be assumed to be present in the base system like this, vs what the snap has to bring with it itself?