selftest: detect if apparmor is unusable and error #5715
Conversation
Under some configuration apparmor may look like its available but we get permission denied errors when trying to use it. This can happen on e.g. an lxd container that runs with: ``` raw.lxc: | lxc.apparmor.profile=unconfined ``` In this case lxd will not setup apparmor stacking so the container looks unconfined however lxd will not grant CAP_MAC_ADMIN to the container (which is quite sensible). But it means that snapd will not be able to setup any apparmor profiles inside such containers. When this is detected snapd will refuse to run because we cannot support this configuration. The host apparmor confinement will interfere with the container and inside the container we can not do anything about this. See the unsuccessful PR snapcore#5621 for an attempt for an attempt to support this environment.
Codecov Report
@@ Coverage Diff @@
## master #5715 +/- ##
==========================================
+ Coverage 78.97% 78.98% +<.01%
==========================================
Files 524 525 +1
Lines 40003 40010 +7
==========================================
+ Hits 31594 31600 +6
- Misses 5841 5842 +1
Partials 2568 2568
Continue to review full report at Codecov.
|
| lxd.lxc start my-ubuntu | ||
| # shellcheck disable=SC2016 | ||
| lxd.lxc exec my-ubuntu -- sh -c 'set -x;for i in $(seq 120); do if journalctl -u snapd.service | grep -E "apparmor detected but insufficient permissions to use it"; then break; fi; sleep 1; done' | ||
| lxd.lxc exec my-ubuntu -- journalctl -u snapd | MATCH "apparmor detected but insufficient permissions to use it" |
There was a problem hiding this comment.
Can we use get_journalctl_log helper here?
There was a problem hiding this comment.
Honestly, I'm not sure, this runs inside the lxc container for which we have no cursor. I think its fine though because we use get_journal_log to avoid reading stuff that was in the journal from previous runs. This lxd container is short-lived so should be ok.
There was a problem hiding this comment.
Why are we doing the same test twice? Is it subtly different or just the same but implemented in a different way?
|
Yay, thank you @jdstrand |
|
I also added https://forum.snapcraft.io/t/running-snapd-inside-lxc-apparmor-profile-unconfined-containers/7032 so that there is a forum reference. I wonder if the error should somehow refer to topic? But maybe googling for it is enough. |
| lxd.lxc start my-ubuntu | ||
| # shellcheck disable=SC2016 | ||
| lxd.lxc exec my-ubuntu -- sh -c 'set -x;for i in $(seq 120); do if journalctl -u snapd.service | grep -E "apparmor detected but insufficient permissions to use it"; then break; fi; sleep 1; done' | ||
| lxd.lxc exec my-ubuntu -- journalctl -u snapd | MATCH "apparmor detected but insufficient permissions to use it" |
There was a problem hiding this comment.
Why are we doing the same test twice? Is it subtly different or just the same but implemented in a different way?
Under some configuration apparmor may look like its available but
we get permission denied errors when trying to use it. This can
happen on e.g. an lxd container that runs with:
In this case lxd will not setup apparmor stacking so the container
looks unconfined however lxd will not grant CAP_MAC_ADMIN to the
container (which is quite sensible). But it means that snapd will
not be able to setup any apparmor profiles inside such containers.
When this is detected snapd will refuse to run because we cannot
support this configuration. The host apparmor confinement will
interfere with the container and inside the container we can
not do anything about this. See the unsuccessful PR
#5621 for an attempt to support this environment.