Ok - so does the opt-in need to be done by all users or just when building the snap?
Also is this expected to be usable for regular snaps in the store? For now I have worked around it by adding code to the application to fallback to adding $SNAP to the path (https://github.com/alexmurray/indicator-sensors/blob/master/plugins/libsensors/is-libsensors-plugin.c#L114), so this is not a blocker but ideally this would be done the ‘correct’ way - which sounds like it has to wait until the layouts stuff is in proper.
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).
Sure no worries - I’ll wait till it is not opt-in as that is not a great user experience for the moment. Who could advise about the udisks2 access issue?
I can be that person. Just looking at the code now I see a potential bug that would cause it not to show up. Let me discuss with my colleagues and get back to you quickly.
I had a deeper look and there’s currently no way to use udisks2 on classic systems. I will discuss this further and see how much work is needed to do that.
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.
Ok - anything I can do to help get udisks2 supported on classic systems? Or is there a way I can just add an apparmor rule to the snapcraft.yaml for indicator-sensors to allow this access?
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.
Developers are not allowed to add arbitrary rules to their snap in this manner. Instead, snapd manages all the security policy for the snap via default policy and interface connections.
What needs to happen is that the udisks interface needs to be updated to allow snaps to access the service on classic systems. I’ve taken a TODO to do this as well.
@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?
@jdstand - also is it possible to request that the :hardware-observe interface is auto-connected otherwise the application doesn’t work out-of-the-box?
We’ve not codified when to add policy-- each is examined on a case by case basis. In this case it was clear that your snap should be able to look at sensors3.conf if it exists because that is what the user would have configured (and if other distros used a different name for the file, we would add it). If /etc/sensors3.conf didn’t exist, your snap could choose to provide sensors-detect to write out a configuration to SNAP_COMMON (or similar) and your snap could use that instead.
It’s a judgement call. For an implicit core interface (ie, it only exists on Ubuntu Core and not classic distro) then we are quite strict that the resource needs to be provided by the core snap (even with that said, the core snap will be slightly different between amd64 and armhf (eg, grub vs uboot) so we might say ‘needs to be provided by some core snap’). With implicit classic interfaces (ie, those on a traditional deb/rpm based distro) we will ask whether it is commonly present in the distro (eg, udisks) and leave it up to the snap to deal with when it isn’t. We’ve been starting to be a little dynamic with that where we check what distro we are running on (eg, recently the calendar-service (evolution data server) is not available on 14.04 cause it is too old), but we don’t yet have a strong concept of dynamic slots yet, so we can’t say, check if udisks is installed and only then expose the slot. This is dynamism is coming and perhaps we can expose interfaces for services in this manner. Currently this exposes a rough edge in snapd where say, password-manager-service is an implicit classic slot, but on server secret-service is not installed. In practice this is not a huge deal because people understand that a server doesn’t provide the desktop environment required by the chromium snap (which uses password-manager-service). With the aforementioned dynamism, we can improve this.
Some things are very clear though-- if a library, file, executable, etc is not in a default install in a typical distro everywhere (eg, adb, java, etc) then the snap needs to ship it and if a snap wants to be sure it works on atypical distros, it should ship the file.
