I mentioned OSTree earlier here. An issue came up with the SELinux integration; to understand it, let me describe how OSTree upgrades work:
1) We perform an rsync-like[1] process to a *new* chroot
2) A "basic" configuration merge is done - we take the new /etc defaults, and apply any modified files on top
Note that the policy.19 file is in /etc.
Crucially, there is at present no %post/postinst type functionality. This is a dramatic increase in reliability over traditional packages. No shell script run as root copy/pasted or just copied from elsewhere appended to everything.
For things like /usr/lib/ld.so.cache which is just a cache, this works fine because it's just referencing things in /usr/lib - it's all precomputed on the compose server.
Now, at least the Fedora selinux-policy has a %post that runs "semodule -B" which recompiles the policy (if the client machine has modified it locally).
Currently with OSTree, what will happen is it will notice the policy.19 file is a modified file in /etc, and simply carry it forward. In other words, updates to the base policy have no effect once the admin has modified it locally.
Administrators *can* rerun "semodule -B" manually after booting into the new root to recompile.
Why can't I just add a %post concept to OSTree? Well, I could. But I'd like to try as hard as conceivably possible to avoid it, and even then only do it where all other avenues are exhausted. For one thing, it would break the ability to do completely offline updates (e.g. open up a VM guest disk from the host, and update it). This ability is presently used to great effect in the testing system.
The primary alternative to %post is a "dynamic merge". For example, systemd has a design where the default unit files are in /usr/lib/system, and then "dropins" can customize them in /etc/systemd/system. On boot, it unions the two.
Similarly, I added /usr/lib/passwd in addition to /etc/passwd:
However...I'm uncertain about doing this for SELinux policy. The policy load happens very early in userspace setup and it's a complex task.
One option is to recompile the policy if we can (we're doing an upgrade from inside a running system, just chroot to new deployment and rerun semodule), and throw an error if we can't do it (the offline upgrade case). The latter would only occur when a machine has a modified policy, which doesn't happen for my testing system.
Any other ideas?
[1] It doesn't share any code with rsync, but the details are irrelevant for this purpose
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
