On Do, 11.04.19 14:19, Steve Grubb (sgrubb(a)redhat.com) wrote:
> > But what, exactly, has cron fallen short in?
> In this case, I was trying to communicate that if systemd, which seems
> to want to replace cron, can't meet all the use cases, we should be
> reporting those that we find in the distro. That lets the systemd
> upstream decide if it is in scope or not and make changes as needed.
From a security point, we'd want the equivalent of cron.allow,
cron.deny. We'd need the pam stack to run just as it did for cron which
means it needs to be privileged and switch to the user account so that
it can correctly recreate the user environment, optionally do auditing
as needed (just like cronie), and it would need to be MLS (Multi-level
If it did all these things, I could see ditching cron. I also have not
looked into the systemd timers to see if or how much of this it
systemd follows a more restrictive approach there: system services and
timers can only be installed by root. If the service uses User= it can
run code as a non-root user that way. If the service uses PAMName=
this can be done through a PAM session if needed.
However, that's intended for system services only (i.e. for services
running as users UID < 1000). For regular users (i.e. human ones,
those with UID >= 1000), the idea is to install timer units in the
per-user instance of the systemd service manager instead. That service
manager runs inside a PAM session of the user, and the lifetime is
normally bound to the time the user is logged in, meaning that users
who are not logged in cannot run stuff. (however, specific users can
be marked as "lingering" though a privileged operation and if so
their specific service manager is started at boot and stays around
until shutdown, so that their timers can run outside of the immediate
login time of the user).
This model is supposed to be a bit more restrictive security-wise than
traditional cron: it's not privileged code that parses and schedules
timer expression and then transitions on each dispatching, but it's
always the user's own code that is responsible for that.
systemd is not a 1:1 replacement for cron, not by a long shot, and
it's not supposed to be. It's supposed to be more restrictive and run
the scheduler itself with the same privileges of the user it shall run
stuff as. There are difference besides lifecycle and security
though. For example, it serializes execution of timer-triggered
services, and merges trigger events.
It never was the intention of to provide the exact same feature set as
cron. And I wouldn't push users who want cron to use systemd timers
instead. But I'd say the semantics and security model we expose in
systemd timers is actually better fitting for the various housekeeping
jobs we ship along with our various RPMs.
Lennart Poettering, Berlin