All snap-based apps stopped working on Debian testing

nodakai · August 4, 2020, 3:04pm

Let me know if you need more info. I’m not knowledgeable with the architecture of snap/snappy/snapcraft

22:57 [nodakai@d9] ~$ snap version               
snap    2.45.2-1
snapd   2.45.2-1
series  16
debian  -
kernel  5.7.0-1-amd64
23:01 [nodakai@d9] ~$ snap run firefox
/usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
23:01 [nodakai@d9] ~$ snap run code   
/usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
23:01 [nodakai@d9] ~$ ldd /usr/lib/snapd/snap-confine 
        linux-vdso.so.1 (0x00007ffc53131000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f331980f000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f3319803000)
        libapparmor.so.1 => /usr/lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f33197ef000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f33197cd000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3319608000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3319871000)

jamesh · August 5, 2020, 6:01am

Do you see any AppArmor errors in the output of dmesg when you try to run a snap app? Perhaps that will explain why snap-confine is failing.

nodakai · August 5, 2020, 6:32pm

Indeed, there were AppArmor errors

[Thu Aug 6 02:13:35 2020] audit: type=1400 audit(1596651203.456:79): apparmor=“DENIED” operation=“open” profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.36" pid=2143732 comm=“snap-confine” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[Thu Aug 6 02:13:35 2020] audit: type=1400 audit(1596651203.456:80): apparmor=“DENIED” operation=“open” profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.36" pid=2143732 comm=“snap-confine” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

I had to update path references to libcap in /etc/apparmor.d to match them with Debian’s MultiArch path conventions. For example, this

/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcap.so* mr,

had to be updated to

/{,usr/}lib{,32,64,x32,x86_64-linux-gnu}/{,@{multiarch}/}libcap.so* mr,

Then I ran sudo apparmor_parser -r (updated file) and tried running a snap app again, hooray, it worked.

Thank you for pointing me to the right direction.

ijohnson · August 5, 2020, 8:24pm

Seems we should update the snap-confine policy for libcap:

github.com

snapcore/snapd/blob/705fd6b57b3811f880e2df0c0c2744cc235fcc6c/cmd/snap-confine/snap-confine.apparmor.in#L40


/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libuuid.so* mr,
# normal libs in order
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libapparmor.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcgmanager.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/{,atomics/}}libdl{,-[0-9]*}.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libnih-dbus.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libdbus-1.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libudev.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libseccomp.so* mr,
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcap.so* mr,
# Needed to run /usr/bin/sh for snap-device-helper.
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libtinfo.so* mr,
@LIBEXECDIR@/snap-confine mr,
/dev/null rw,
/dev/full rw,
/dev/zero rw,
/dev/random r,
/dev/urandom r,

jamesh · August 6, 2020, 1:07am

nodakai:

I had to update path references to libcap in /etc/apparmor.d to match them with Debian’s MultiArch path conventions. For example, this
/{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libcap.so* mr,
had to be updated to
/{,usr/}lib{,32,64,x32,x86_64-linux-gnu}/{,@{multiarch}/}libcap.so* mr,
Then I ran sudo apparmor_parser -r (updated file) and tried running a snap app again, hooray, it worked.

It’s not clear your change is necessary: it is expanding the pattern to match directories like /libx86_64-linux-gnu/..., which doesn’t match the path shown in the error messages. The /x86_64-linux-gnu/ component should already be handled by the /{,@{multiarch}/} part of the pattern.

I wonder if reloading the original unmodified policy with apparmor_parser would have solved the problem too?

nodakai · August 6, 2020, 2:40am

Hmm, I reverted my local changes, reloaded the configs, and apps still worked. So probably all I needed was just systemctl reload apparmor. But I’d assume that should have happened automatically? Let me know if you need more logs from my machine