Confinement help with snapping indicator-sensors

snapcraft
1

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")

I have added udisks2 and hardware-observe to the plugs but this doesn’t seem to have any effect: https://github.com/alexmurray/indicator-sensors/blob/master/snap/snapcraft.yaml#L31 - any ideas would be greatly appreciated as I would love for this to run with confinement in strict mode but so far it is proving challenging.

2

You can use a layout to re-map /etc/sensors3.conf to $SNAP_DATA/sensors.conf, for example.

Please look at Layouts: re-mapping snap directories

3

Thanks - can you advise on the syntax - I tried adding it as a symlink but that failed:

layout:
  /etc/sensors3.conf:
    symlink: $SNAP_DATA/sensors3.conf

$ snapcraft cleanbuild
Issues while validating None: Additional properties are not allowed ('layout' was unexpected)
4

Oh? I think you may need to use the passthrough property. I suspect that layout will be supported officially in snapcraft but for now you can do this:

passthrough:
    layout:
        /etc/sensors3.conf:
            symlink: $SNAP_DATA/sensors3.conf

You also need to opt-into layout (beta feature) upon installation with this command:

snap set core experimental.layouts=true
5

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.

6

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).

7

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?

8

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.

9

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.

10

What do you mean by classic systems? I am using Ubuntu 18.04 and snapcraft installed via snap if that helps to clarify.

11

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.

12

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?

13

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.

14

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.

15
16

@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?

1 Like
17

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).

18

This is committed to master and the upcoming 2.33.

19

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?

20

@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?