On Thu, 2015-03-26 at 13:23 +0100, Jan Pazdziora wrote: > On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: > > > > From an SELinux standpoint systemd is far superior to initd as it allows > > far more graceful domain transitions. > > Have you got a link which would demonstrate how systemd helps > with domain transitions?
Hi everyone, before answering to the technical question I would like to ask that people refrain from comments on how good/bad systemd is, it is an inflammatory topic and people has really discussed it to no end all over the internet. I do not think we need to make camps here. Now on the SELinux thing, the init system (any init system) can transition easily to any domain it wants as it is the first process and it is explicitly given that permission by policy. The way systemd works when you run a unit file is that systemctl communicates to the init system commanding it to styart a specific unit file, then the init system does it setting up the appropriate SELinux context for the process. This is always consistent as calling systemctl is the only way to run a unit file. With the old sysV system (on Fedora/RHEL), instead the admin (root usually) had at least 2 ways of starting an init script. 1) use the service command 2) run the script directly Now if (1) was used then the service command could do a transition to the initd_t domain first and then be allowed to transition the script it would launch to the appropriate domain (just like init would do at boot). However if the admin directly executed the script instead of using the service command then this would not happen because there are no transition rules when root runs stuff directly. Root happens to have the unconfined_t role and so whatever it executes directly, normally, will inherit the same, which means unfettered access to most of the system. In turn this means the program may create files which also also marked unconfined_t (or other label not normally available to the program). Upon reboot (or proper restart via service file) the program would go back to start with the correct policy and find itself with no access to those files due to mismatching label (or behave differently due to different access to config files and the like). This was often the cause of hate by admins that do not understand the mechanics and nuances involved in using SELinux. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project