Apparmor and symlink for /etc/os-release -> pop-os/os-release

snapd
1

grep -i apparmor /var/log/kern.log

...
Jan 30 17:08:58 arkanoid kernel: [454802.377170] audit: type=1400 audit(1643558938.711:363714): apparmor="DENIED" operation="open" profile="/snap/snapd/14549/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=2653748 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:08:58 arkanoid kernel: [454802.379449] audit: type=1400 audit(1643558938.711:363715): apparmor="DENIED" operation="open" profile="snap.lxd.daemon" name="/var/lib/snapd/hostfs/etc/pop-os/os-release" pid=2653748 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:01 arkanoid kernel: [454804.880292] audit: type=1400 audit(1643558941.211:363716): apparmor="DENIED" operation="open" profile="/snap/snapd/14549/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=2654050 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:01 arkanoid kernel: [454804.882668] audit: type=1400 audit(1643558941.215:363717): apparmor="DENIED" operation="open" profile="snap.lxd.daemon" name="/var/lib/snapd/hostfs/etc/pop-os/os-release" pid=2654050 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:03 arkanoid kernel: [454807.360090] audit: type=1400 audit(1643558943.691:363718): apparmor="DENIED" operation="open" profile="/snap/snapd/14549/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=2654298 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:03 arkanoid kernel: [454807.362372] audit: type=1400 audit(1643558943.695:363719): apparmor="DENIED" operation="open" profile="snap.lxd.daemon" name="/var/lib/snapd/hostfs/etc/pop-os/os-release" pid=2654298 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:06 arkanoid kernel: [454809.883137] audit: type=1400 audit(1643558946.215:363720): apparmor="DENIED" operation="open" profile="/snap/snapd/14549/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=2654562 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 30 17:09:06 arkanoid kernel: [454809.885500] audit: type=1400 audit(1643558946.219:363721): apparmor="DENIED" operation="open" profile="snap.lxd.daemon" name="/var/lib/snapd/hostfs/etc/pop-os/os-release" pid=2654562 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
...

os-release is a symlink to pop/os-release

lrwxrwxrwx 1 root root 17 ene 11 09:01 os-release -> pop-os/os-release

cat /etc/os-release

    NAME="Pop!_OS"
    VERSION="21.10"
    ID=pop
    ID_LIKE="ubuntu debian"
    PRETTY_NAME="Pop!_OS 21.10"
    VERSION_ID="21.10"
    HOME_URL="https://pop.system76.com"
    SUPPORT_URL="https://support.system76.com"
    BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
    PRIVACY_POLICY_URL="https://system76.com/privacy"
    VERSION_CODENAME=impish
    UBUNTU_CODENAME=impish
    LOGO=distributor-logo-pop-os

uname -a Linux myhost 5.15.15-76051515-generic #202201160435~1642693824~21.10~97db1bb SMP Thu Jan 20 17:35:05 U x86_64 x86_64 x86_64 GNU/Linux

snap list

Nombre   Versión   Rev    Seguimiento    Editor        Notas
certbot  1.22.0    1670   latest/stable  certbot-eff✓  classic
core20   20220114  1328   latest/stable  canonical✓    base
lxd      4.0.8     21835  4.0/stable/…   canonical✓    -
snapd    2.54.2    14549  latest/stable  canonical✓    snapd

I’m following the advice from the linuxcontainers forum and bringing the issue here up:

The fact that the command reported here is snap-exec means that it’s unlikely to be something we can really help with in LXD.

There is a system-observe interface in snapd which allows access to /etc/os-release I believe. But apparmor follows all symlinks, so assuming your /etc/os-release is a symlink to /etc/pop-os/os-release, this would explain the failure.

A quick workaround would be for you to turn /etc/os-release into a regular file rather than a symlink. A proper fix would be to have snapd also allow /etc/pop-os/os-release everywhere it allows /etc/os-release, but it’s an unusual pattern that pop-os is following here and that may well be breaking a bunch of other software for no real good reason (the standard is for /etc/os-release or /usr/lib/os-release to be regular files, not symlinks).

I’d recommend bringing this up on https://forum.snapcraft.io

Could you pleaase adapt apparmor to follow the link for os-release? Or is this a bad approach? Should I bring this up to the pop os team (pop system76 com) ? Thanks.

2

What is the content of /usr/lib/os-release then?

3

if you search the forum you will find quite a few other issues caused by popos applying his awful hack that does not respect the FDO standard.

This really needs to be fixed by popos by properly changing the base-files deb package in their repository and simply providing a proper /etc/os-release as debian derivatives of any kind normally do …

(this will not only cause snap issues, there are plenty of other tools and apps that check os-release in the standard path that can mis-function due to this, they can not expect the whole downstream world to apply hacks to their software to compensate for their non-standard behavior)

4

Unfortunately, the FDO manpage doesn’t state that this is against the rules. See this quote:

(emphasis mine)

I do agree that Pop!_OS are doing something unusual, though, and it would be better if they could do things the same way as the rest of the world.

1 Like
5

As @lucyllewy noted, they don’t violate the FDO standard at all, as the standard itself says that those files can be symlinks. While it is a bit out of the established pattern, it’s also not the first time I’ve seen a distro do this.

I would argue that since the FDO standard makes an allowance for symlinks, then any tool relying on the os-release file should also be making that allowance.

1 Like