On Do, 11.04.19 14:19, Steve Grubb (sgrubb@xxxxxxxxxx) 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 > Security) capable. > > 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 > currently does. 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 -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
