=== not_phunyguy is now known as phunyguy
=== not_phunyguy is now known as phunyguy
[06:46] <mborzecki> morning
[07:49] <mardy> hi mborzecki 
[07:53] <mborzecki> o/
[08:02] <pstolowski> morning
[08:11] <zyga[m]> good morning
[09:25] <mup> PR snapd#11436 closed: o/devicestate, daemon: introduce factory-reset mode, allow switching <factory reset 🔌> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/11436>
[09:35] <mup> PR snapd#11487 opened: snap: Add missing zlib <Created by valentindavid> <https://github.com/snapcore/snapd/pull/11487>
[11:02] <mardy> forgive my ignorance, but in "Ubuntu Core 20", does the "20" mean that the image is based on Focal packages?
[11:05] <mup> PR snapd#11488 opened: i/seccomp/template.go: add close_range to the allowed syscalls <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11488>
[11:25] <mup> PR snapd#11489 opened: o/devicestate: split mocks to separate calls for creating a model and a gadget <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11489>
[12:03] <mborzecki> mardy: yeah, that is my understanding
[12:04] <mborzecki> we also have uc18 which is based on bionic, in theory there was uc16 too, though core16 was never released to stable, so there was just ubuntu core based on the 'core' snap
[12:07] <mardy> mborzecki: thanks for confirming!
[12:20] <mup> PR snapd#11481 closed: i/a/template.go: add ld path for jammy <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11481>
[12:26] <mup> PR snapd#11485 closed: interfaces/apparmor: Update base template for systemd-machined <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11485>
[12:31] <mup> PR # closed: snapd#11482, snapd#11486, snapd#11487, snapd#11489
[13:21] <mup> PR snapd#11490 opened: tests: set interfaces-cups-control test to manual <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11490>
[14:51] <mup> PR snapd#11491 opened: interface/opengl: allow read on /proc/sys/dev/i915/perf_stream_paranoid <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/11491>
[15:56] <mup> PR snapd#11492 opened: o/devicestate: restore device key and serial when assertion is found <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11492>
[17:05] <stgraber> did something change in snapd/snap-confine recently? I'm seeing a LOT of failures in containers
[17:05] <stgraber> root@a:~# distrobuilder 
[17:05] <stgraber> cannot change profile for the next exec call: No such file or directory
[17:05] <stgraber> is what I'm getting for running a classic snap inside of a container
[17:08] <ijohnson[m]> there was a CVE fixed related to snap-confine recently 
[17:09] <ijohnson[m]> stgraber: is this an unprivileged lxd Container? 
[17:13] <stgraber> ijohnson[m]: that one is privileged actually
[17:14] <stgraber> ijohnson[m]: that's the setup we use for image building (where we need to be able to mount stuff occasionally)
[17:16] <stgraber> I guess I'll have to build snapd by hand to debug this because the error isn't useful and you can't trace it without changing its behavior
[18:19] <ijohnson[m]> stgraber: do you see any output if you run the command with SNAPD_DEBUG=1
[19:02] <stgraber> ijohnson[m]: https://gist.github.com/stgraber/33f9d1d81ab7e7b83b6f69b84db33a1d
[19:02] <stgraber> ijohnson[m]: so trying to load a profile which doesn't exist
[19:02] <stgraber> ijohnson[m]: what normally causes the profiles to be loaded?
[19:04] <stgraber> Mar 11 17:03:58 a snapd[385]: AppArmor status: apparmor_parser is available but required parser features are missing: unsafe
[19:05] <stgraber> so that may be a problem
[19:13] <ijohnson[m]> stgraber: usually there's a snapd.apparmor.service that loads them as a backup if they aren't automatically loaded 
[19:13] <ijohnson[m]> I'm afk so I don't remember the exact name of the service 
[19:14] <ijohnson[m]> But normally apparmor will load profiles in /var/lib/snapd/apparmor/profiles/... 
[19:14] <ijohnson[m]> *automatically load 
[19:17] <stgraber> looks like I'm hitting a variation of https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143
[19:17] <mup> Bug #1648143: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_<var-lib-lxd>" profile="unconfined" name="system_tor" <apparmor> <lxd> <tor> <verification-done-xenial> <verification-done-yakkety> <apparmor (Ubuntu):Invalid> <linux (Ubuntu):Fix Released> <tor
[19:17] <mup> (Ubuntu):Invalid> <linux (Ubuntu Xenial):Fix Released> <tor (Ubuntu Xenial):Invalid> <linux (Ubuntu Yakkety):Fix Released> <tor (Ubuntu Yakkety):Invalid> <https://launchpad.net/bugs/1648143>
[19:17] <stgraber> so something regressed somewhere...
[19:20] <ijohnson[m]> Hmmm yeah I'm not sure what's to blame, i assume apparmor on the hose is fine, but also if you've got a privileged container I'm not sure 
[19:24] <stgraber> looks like a kernel regression
[19:25] <stgraber> 5.4.0 is fine, 5.13.0 isn't (latest build of each), going to see if an earlier 5.13.0 is also affected
[19:37] <stgraber> ijohnson[m]: ● snapd.apparmor.service loaded failed failed Load AppArmor profiles managed internally by snapd
[19:38] <stgraber> ijohnson[m]: Mar 11 19:31:44 priv snapd-apparmor[166]: AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap-confine.snapd.14978 in /var/lib/snapd/apparmor/snap-confine/cap-bpf at line 2: Invalid capability bpf.
[19:38] <stgraber> which in turn prevents the profiles from being generated and causes the load failure as there's nothing to load
[19:44] <stgraber> ijohnson[m]: ah, so the confusing thing is that when the profile is generated+loaded at snap install time, it's all good, when it's loaded on boot, it fails causing the issue
[19:58] <stgraber> ijohnson[m]: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1964636
[19:58] <mup> Bug #1964636: Incorrect handling of apparmor `bpf` capability <snapd (Ubuntu):New> <https://launchpad.net/bugs/1964636>
[20:12] <ijohnson[m]> stgraber: thanks it actually sounds very familiar to an issue I saw a while ago, I'll have a look