rodnymolina
commented
1 year ago The error above is observed while dockerd is attempting to load the docker-default apparmor profile during the initialization of the inner container.
Notice that apparmor profiles are usually not enforced in traditional docker-in-docker scenarios to prevent errors caused by attempting to write to read-only file-systems such as sysfs (i.e., /sys/kernel/security/apparmor).
// hostSupports returns true if apparmor is enabled for the host, if
// apparmor_parser is enabled, and if we are not running docker-in-docker.
//
// This is derived from libcontainer/apparmor.IsEnabled(), with the addition
// of checks for apparmor_parser to be present and docker-in-docker.
func hostSupports() bool {
checkAppArmor.Do(func() {
// see https://github.com/opencontainers/runc/blob/0d49470392206f40eaab3b2190a57fe7bb3df458/libcontainer/apparmor/apparmor_linux.go
if _, err := os.Stat("/sys/kernel/security/apparmor"); err == nil && os.Getenv("container") == "" {
if _, err = os.Stat("/sbin/apparmor_parser"); err == nil {
buf, err := os.ReadFile("/sys/module/apparmor/parameters/enabled")
appArmorSupported = err == nil && len(buf) > 1 && buf[0] == 'Y'
}
}
})
return appArmorSupported
}This code is prone to error given that it relies on the presence of the container env-variable, which may not be defined in the execution context in which the inner dockerd operates. This env-variable is typically set by the container's high-level runtime operating in the host, but this is not always the case, e.g., docker doesn't do it -- see example below for cri-o's containers:
# echo $container
crioNow, even in scenarios where this env-variable is present, chances are that it may not be taken into account if dockerd is launched through a process-manager such as systemd, which means that this container variable ends up being undefined and, in consequence, dockerd attempts to load the apparmor profile indicated above (i verified this by looking at strace dumps).
As a workaround for this problem we could attempt to adjust Docker's systemd file within each of the Sysbox's published images to set the container variable, but that wouldn't fix the problem for those users that install dockerd by themselves if they were to rely on generic sysbox's image such as ubuntu-jammy-systemd.
grzesuav
In scenarios where recent versions of the docker-engine (>= 23.0.1) are installed within sysbox containers, the following error may be seen while attempting to run inner containers:
Issue was initially reported by @grzesuav -- thanks for that!