[Freeipa-users] Is systemd really a requirement for freeipa 4.x?

[Simo Sorce]

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