For security reasons, we enabled the smack feature on the host machine (for example, adding: security=smack in grub), but the customer's container did not set the "container=docker" environment variable, which caused the container to fail to start.

We observe the following code:

static const MountPoint mount_table[] = {
        { "sysfs",       "/sys",                      "sysfs",      NULL,                      MS_NOSUID|MS_NOEXEC|MS_NODEV,
          NULL,          MNT_FATAL|MNT_IN_CONTAINER },
…
#if ENABLE_SMACK
        { "smackfs",     "/sys/fs/smackfs",           "smackfs",    "smackfsdef=*",            MS_NOSUID|MS_NOEXEC|MS_NODEV,
          mac_smack_use, MNT_FATAL                  },
        { "tmpfs",       "/dev/shm",                  "tmpfs",      "mode=1777,smackfsroot=*", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
          mac_smack_use, MNT_FATAL                  },
#endif
...
}

static int mount_one(const MountPoint *p, bool relabel) {
…
        /* Skip securityfs in a container */
        if (!(p->mode & MNT_IN_CONTAINER) && detect_container(NULL) > 0)
                return 0;
…
}

MNT_IN_CONTAINER is not set in the smackfs item, but it is still mounted in the container. The reason is that the "container=docker" environment variable is not set, which causes the detect_container to fail to detect the container environment.

We need to make some enhancements to the detect_container() function. Even if the "container=docker" environment variable is not set, we hope it can still detect the container environment and enhance the robustness of systemd.


Finally, we found that the following patch can solve this problem:
https://github.com/systemd/systemd/commit/342bed02084c4396dd2f1054bd559bfb2699cfcb