[03:52] <jamesh> amurray: thanks for the feedback on the removable-media PR. It wasn't clear to me whether the lack of map/execute permissions was just from caution or had more reasons. I guess I'll simplify the PR down to an unconditional change then.
[04:15] <amurray> jamesh: hey - I assume it was done specifically but as you say, since there is nothing stopping a snap from copying an existing executable from a removable-media device over to somewhere it can already execute from then we may as well just add it as execute for simplicity
[04:21] <amurray> e.g. https://paste.ubuntu.com/p/86W8P8HddW/
[04:27] <jamesh> amurray: one other thing I was working on that you might find interesting: a libseccomp patch to let it do 32-bit argument comparisons on 64-bit systems: https://github.com/seccomp/libseccomp/pull/384
[04:27] <mup> PR seccomp/libseccomp#384: RFE: add support for comparisons against 32-bit arguments <enhancement> <priority/medium> <pending/review> <Created by jhenstridge> <https://github.com/seccomp/libseccomp/pull/384>
[04:28] <jamesh> Once we get that in, it should help simplify some of the seccomp filters by making them only act on data the syscall actually uses.
[04:29] <jamesh> making it harder to bypass
[04:38] <amurray> jamesh: thanks - yeah I saw that (I am subscribed to notifications for the upstream libseccomp github project) - that is awesome - I always find libseccomp code a bit gnarly - nice work
[06:03] <mborzecki> morning
[07:08] <pstolowski> morning
[07:27] <mardy> hi all
[07:37] <mup> PR snapd#11705 closed: interfaces,overlord: add support for adding extra mount layouts <Created by Meulengracht> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11705>
[07:52] <mup> PR snapd#11742 closed: cmd/snap-bootstrap: Listen to keyboard added after start and handle switch root <Created by valentindavid> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11742>
[07:52] <mup> PR snapd#11779 closed: cmd/snap-fde-keymgr: support for multiple devices and authorizations for add/remove recovery key <factory reset 🔌> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11779>
[07:57] <mup> PR snapd#11704 closed: tests: Apparmor sandbox profile mocking <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/11704>
[08:11] <mardy> do you also get an error when accessing https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap ?
[08:29] <pstolowski> mardy: I do
[08:30] <pstolowski> Unable to contact snapident. Too many retries
[08:37] <mardy> pstolowski: thanks, that's comforting, in a way :-)
[08:38] <pstolowski> mardy: might be worth reporting it to the store people
[08:53] <mardy> pstolowski: seems to be working now
[09:00] <diddledani> status.snapcraft.io shows it was down
[09:02] <mardy> mborzecki: OK, I finally understood the problem: the capabilities are blocked by AppArmor. cap_fowner is not in the profile, and for some reason no warning was being logger. I'm going to test this assumption soon, but I'm confident that that's it
[09:02] <mardy> diddledani: oh, I didn't even know of that. Thanks :-)
[09:04] <mborzecki> mardy: haha, maybe there's an explicit deny in one of the base abstractions we include, as a result there's no explicit denial logged
[09:27] <mup> PR snapd#11799 opened: [WIP] many: optional recovery keys <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11799>
[09:42] <mup> PR snapd#11800 opened: cmd/snap-fde-keymgr: best effort idempotency of add-recovery-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11800>
[10:03] <mup> PR snapd#11756 closed: tests: add spread test to verify that connections are preserved if snap refresh fails <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/11756>
[11:03] <diddledani> omg, mardy, if you're right about apparmor killing the caps that will be an amazing discovery
[11:04] <diddledani> that re-opens the door to getting that bug fixed
[11:12] <mardy> diddledani: oh, yes, I think we are close
[11:12] <diddledani> 🤞
[11:17] <mardy> mborzecki: do I understand correctly, that sc_reassociate_with_pid1_mount_ns() is needed for those cases when snap-confine is invoked from within a snap? That is a snap invoking another snap?
[11:20] <mborzecki> mardy: hm you could unshare -m and then invoke a snap, in which case things may go bad, so this way we start from a known state and have a reproducible result
[11:20] <mborzecki> at least that's my understanding
[11:22] <mborzecki> it'd be actually somewhat funny if the system was organized in a way that eg. removable device mounts are only visible in say your private mount ns
[11:28] <diddledani> unrelated to snap, but I know we have mount namespace experts here - My systemd-on-wsl2 work creates a few namespaces for systemd to start up inside so it sees itself as pid 1. One of the namespaces it needs is a mount namespace. The problem I'm encountering with that is `wsl --mount` from Windows doesn't propagate into the mount namespace - is there a way of ensuring that mount changes outside the namespace are propagated into
[11:31] <mborzecki> diddledani: wsl --mount mounts something form the host?
[11:31] <diddledani> yes, it can mount physical disks/partitions from the host into the WSL VM
[11:31] <mborzecki> diddledani: sounds lke something somewhere should be set up with slave propagation
[11:32]  * diddledani googles
[11:37] <mborzecki> diddledani: we set up slave propagation for /snap, /media and /mnt such that mounts that appear there would appear in the snap mount ns (actually IIRC /mnt and /media are shared iirc so that snaps can mount things)
[11:37] <mborzecki> but /snap is definitely slave, so when a new snap (or rev) comes in, it's visible in the existing mount namespaces
[11:46] <diddledani> mborzecki: you're awesome. thank you - that helped me with the right google terms and I just discovered the unshare option of `--propagation shared` which seems to do the job perfectlyy
[11:58] <diddledani> fixed my systemd installer to do this now https://github.com/diddledani/one-script-wsl2-systemd/blob/4dc64fba72251f1d9804ec64718bb005e6b27b62/install.ps1#L460
[12:43] <mup> PR snapd#11794 closed: interfaces: allow map and execute permissions for files on removable media <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11794>
[14:14] <mup> PR snapd#11801 opened: many: add NoStateError and a checker for tests <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/11801>
[14:19] <mup> PR snapd#11782 closed: tests: improve the unit testing workflow to run in parallel <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11782>
[14:19] <mup> PR snapd#11802 opened: .github: Trigger daily riscv64 snapd edge builds <Created by xnox> <https://github.com/snapcore/snapd/pull/11802>
[14:29] <mup> PR snapd#11798 closed: asserts/info,mkversion.sh: capture max assertion formats in snapd/info <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11798>
[15:09] <mup> PR snapd#11803 opened: cmd/snap-confine: remove setuid calls from cgroup init code <Created by mardy> <https://github.com/snapcore/snapd/pull/11803>
[15:17] <jdstrand_> mardy, mborzecki: note that the kernel won't always log capability denials in the way you expect. I found it is best to 'sudo sysctl -w kernel.printk_ratelimit=0' to turn off rate-limiting, reloading the profile into the kernel and then trying to reproduce the denial. combined, that should make it pop out. you'll likely need to reload the profile before trying to reproduce again to see the logging. I 
[15:18] <jdstrand_> forget the specifics otoh, but jj could provide more details
[15:19] <jdstrand> (essentially, where capability checks happen they can be quite noisy so the kernel tries to show the first one. the reload seems to reset that. again, I forget the details but it is something along those lines)
[19:26] <mardy> jdstrand: thanks!