I think this question was already asked but I could not find the discussion. What would be the challenges to support a monolitic policy on a volatile root? In a volatile root scenario there is only a non-volatile readonly /usr. Would it be possible to teach libselinux that if there is a /usr/selinux and not a /etc/selinux and/or /var/lib/selinux that it would use that instead? The challenge I am currently facing with systemd.volatile=yes is that when the policy is loaded from initramfs that systemd-tmpfiles (and systemd-sysusers) cannot properly populate root from /usr/share/factory (or created) because they rely on libselinux,get/setfilecon and thus on /etc/selinux/contexts/files. There is a slight chicken and egg situation there. Often times its not a probable because one can do with automatic type transitions but some of these files get created atomically (/etc/passwd and /etc/shadow for example) and not to mention that these libselinux linked components might get confused and noisy if selinux is enabled and enforcing but there is no /etc/selinux. Duplicating policy in initramfs and /etc, /var/lib would invite inconsistencies and is not feasible but if the policy is readonly and thus monolitic then this might be feasible if it is not too ugly. Actually in such a scenario we would probably not need a policy in initramfs at all since systemd would just load it from /usr instead of /etc. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@xxxxxxxxxxx
