/srv/irclogs.ubuntu.com/2022/05/18/#snappy.txt

=== stgraber_ is now known as stgraber
jameshamurray: 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.03:52
amurrayjamesh: 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 simplicity04:15
amurraye.g. https://paste.ubuntu.com/p/86W8P8HddW/04:21
jameshamurray: 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/38404:27
mupPR 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:27
jameshOnce 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:28
jameshmaking it harder to bypass04:29
amurrayjamesh: 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 work04:38
mborzeckimorning06:03
pstolowskimorning07:08
mardyhi all07:27
mupPR 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:37
mupPR 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
mupPR 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:52
mupPR snapd#11704 closed: tests: Apparmor sandbox profile mocking <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/11704>07:57
mardydo you also get an error when accessing https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap ?08:11
pstolowskimardy: I do08:29
pstolowskiUnable to contact snapident. Too many retries08:30
mardypstolowski: thanks, that's comforting, in a way :-)08:37
pstolowskimardy: might be worth reporting it to the store people08:38
mardypstolowski: seems to be working now08:53
=== ackk is now known as ack
diddledanistatus.snapcraft.io shows it was down09:00
mardymborzecki: 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 it09:02
mardydiddledani: oh, I didn't even know of that. Thanks :-)09:02
mborzeckimardy: haha, maybe there's an explicit deny in one of the base abstractions we include, as a result there's no explicit denial logged09:04
mupPR snapd#11799 opened: [WIP] many: optional recovery keys <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11799>09:27
mupPR snapd#11800 opened: cmd/snap-fde-keymgr: best effort idempotency of add-recovery-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11800>09:42
mupPR 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>10:03
diddledaniomg, mardy, if you're right about apparmor killing the caps that will be an amazing discovery11:03
diddledanithat re-opens the door to getting that bug fixed11:04
mardydiddledani: oh, yes, I think we are close11:12
diddledani🤞11:12
mardymborzecki: 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:17
mborzeckimardy: 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 result11:20
mborzeckiat least that's my understanding11:20
mborzeckiit'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 ns11:22
diddledaniunrelated 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 into11:28
mborzeckididdledani: wsl --mount mounts something form the host?11:31
diddledaniyes, it can mount physical disks/partitions from the host into the WSL VM11:31
mborzeckididdledani: sounds lke something somewhere should be set up with slave propagation11:31
* diddledani googles11:32
mborzeckididdledani: 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
mborzeckibut /snap is definitely slave, so when a new snap (or rev) comes in, it's visible in the existing mount namespaces11:37
diddledanimborzecki: 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 perfectlyy11:46
diddledanifixed my systemd installer to do this now https://github.com/diddledani/one-script-wsl2-systemd/blob/4dc64fba72251f1d9804ec64718bb005e6b27b62/install.ps1#L46011:58
mupPR 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>12:43
mupPR snapd#11801 opened: many: add NoStateError and a checker for tests <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/11801>14:14
mupPR 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
mupPR snapd#11802 opened: .github: Trigger daily riscv64 snapd edge builds <Created by xnox> <https://github.com/snapcore/snapd/pull/11802>14:19
mupPR 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>14:29
mupPR snapd#11803 opened: cmd/snap-confine: remove setuid calls from cgroup init code <Created by mardy> <https://github.com/snapcore/snapd/pull/11803>15:09
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:17
jdstrand_forget the specifics otoh, but jj could provide more details15:18
=== jdstrand_ is now known as jdstrand
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)15:19
=== benfrancis6 is now known as benfrancis
mardyjdstrand: thanks!19:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!