snap-confine: add `tmpfs` mount rule to apparmor profile
After a fresh boot with the lunar proposed kernel 6.2.0-23.23 with the snapd from `edge/prompting` revision 19342 and 19399 (and the apparmor userspace build from https://gitlab.com/jjohansen/apparmor.git and the "prompt" branch). I cannot produce this with the snapd from "edge" that vendors a slightly older version of apparmor userspace.
Looking at the apparmor profiles we generate for `snap-confine` I could indeed not find a rule that allows snap-confine to mount the scratch dir that should be needed in `mount-support.c:sc_bootstrap_mount_namespace()`.
The relevant code looks like this: ``` sc_do_mount("none", scratch_dir, NULL, MS_UNBINDABLE, NULL); if (config->normal_mode) { sc_initialize_ns_fstab(config->snap_instance); // Create a tmpfs on scratch_dir; we'll them mount all the root // directories of the base snap onto it. sc_do_mount("none", scratch_dir, "tmpfs", 0, NULL); sc_replicate_base_rootfs(scratch_dir, config->rootfs_dir, config->mounts); ``` and indeed `strace` confirms this mount is taking place: ``` [pid 15281] mount("none", "/tmp/snap.rootfs_w5Tw1R", "tmpfs", 0, NULL) = -1 EACCES (Permission denied) ```
Manually adding the following rule to the `snap-confine` profile: ``` mount fstype=tmpfs none -> /tmp/snap.rootfs_*/, ``` and ``` $ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine.snapd.19342 ``` made snaps work again.
This is puzzling because AFAICT the rule is really missing and the mount should be denied but it's only denied with the vendored userapce from the `edge/prompting` snap.
github: remove use of `covertool merge` to fix codecov reporting (#12837)
The codecov reporting was broken for a while and after some slightly painful debugging in PR#12834 it turns out that the use of `covertool merge` seems to break codecov. Using this is not needed as codecov can merge reports natively.
This commit removes the use of `covertool merge` and instead just send the various generated coverage reports to codecov.
Now offset-write for a structure will always be absolute. A value for relative-to will still be accepted only if it refers to a structure with zero offset.
gadget: remove offset-write from gadget structure content
Using offset-write from an image in a gadget volume structure content was never implemented by ubuntu-image and does not seem too useful. Removing it and the related checks therefore.
