On Tue, Mar 25, 2014 at 1:13 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
Can you explain when/why you cannot run semodule -B? As long as you also pass it -n and -s <store-name> and possibly -p <rootpath>, it should work and should not affect the running system until reboot or next policy load.
Right. The first reason is at the moment I have an update system that *has no %post at all*. It's much less flexible than traditional packages, but is much more reliable.
I have two high level concerns:
1) If I'm running arbitrary code, I want it to be started by systemd and ensure any log messages from it go to the journal, any error code is tracked, any processes started are properly cleaned up, etc. Were I to add a %post type thing I'd likely use systemd-nspawn for this to ensure that /proc is mounted and all other requirements are met.
On the other hand, if it's just SELinux for now I may just commit support into the ostree core to recompile the policy in the new root directly from the main process and not fork off any other tool.
2) External tools may not match the "fdatasync policy". Looking at the implementation of semanage_direct_commit() in selinux/libsemanage/src/direct_api.c, we create empty files, but don't open the parent directory fd and sync it. Similarly, semanage_write_policydb() appears to just use fclose() and does not attempt to fdatasync() the policy file on disk.
This has been a real world problem with other triggers like gtk-update-icon-cache. RPM is pretty careful to fdatasync() files it writes to disk. But until:
if you pulled the power after RPM said a "transaction" was complete, you could end up with a corrupted icon cache.
Now I admit, right now in OSTree I am simply doing a global sync() before swapping the bootloader configuration:
But that's a short term hack since sync() doesn't return errors, and it forces a flush of *everything* which can be a major performance hit.
On the other hand, there are cases where we *don't* want to fdatasync(), like constructing mock/pbuilder type build roots. Some discussion here:
Effectively semodule -B is performing a merge, by merging any local policy customizations into the updated policy. You do want the merge because the updated policy may include changes required for the updated system components, while the local customizations may be required for system operation (e.g. local file_contexts entries, boolean settings, login mappings, added allow rules for third party software or non-standard configurations), so using either just the modified policy from before the upgrade or just the unmodified updated policy could leave the system in a non-functional state.
Right, absolutely. I want policy updates to work with local configuration as they do with traditional packages. I also want upgrades to be fully atomic. The goal is to do both =)
_______________________________________________ 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.
