I’m seeing many messages from Apparmor saying that (re?)mounting rootfs was denied. The container is running Fedora 43 and is privileged. As far as I can tell, the container is working without any problem.
AppArmor mount rules get very messy these days because of the new mount API and lack of context being made available to AppArmor to handle those cases.
In this scenario, the requested action as shown in the log could be a security issue for a privileged container as it would allow a recursive bind-mount of / (including /proc) to be made available at /run/systemd/mount-rootfs/. As AppArmor is path based, all rules that would apply to say /proc won’t apply to /run/systemd/mount-rootfs/proc/, allowing the rules to be bypassed.
So the policy attempting to block this actually seems correct, but that may have some negative impact on those systemd units, which ironically enough are hitting this issue as part of the Protect rules which are meant to protect the system by better isolating that service…
Anyway, TLDR is, avoid privileged containers if you can. We have to do a lot of weird tricks to make them feel vaguely safe and those tricks unfortunately often cause some collateral damage.
The container is privileged to allow it to do an NFS mount.
The choices seem to be (1) use a privileged container or (2) NFS mount on the host and bind-mount into an unprivileged container. The first has security issues and ignoring AppArmor messages is not appealing. The second breaks isolation between host and container and adds to clutter on the host.
As you have mentioned elsewhere, someday someone might figure out what NFS functions should be permitted in an unprivileged container. While I believe in “scratching my own itch”, I think that’s more than I want to pursue.
Apparently, bind-mount only allows read access to host directories and shift=true does not work. That seems to leave fuse-nfs mount in the container as the third option.
Yes, I did test this. I re-ran the test and discovered that there was a idmap issue on the host, where the uid/gid on the files in the NFS mount were mapped to “nobody”. Fixing that issue corrected the problem in the container.
BTW setting shift=true results in an error starting the container (“idmapping abilities are required but aren’t supported on system”). Removing this seems to work.