[arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=. This means that we could replace the cron.* dropin scripts with systemd services and timers. Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems Affected packages: community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8 /etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.
On Fri 28, March 01:01:22 Thomas Bächler wrote:
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron:
Cool!
I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.
+1 from me -- Andrea Arch Linux Developer
On 28/03/14 10:05, Andrea Scarpino wrote:
On Fri 28, March 01:01:22 Thomas Bächler wrote:
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron:
Cool!
I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.
+1 from me
Agreed. +1
On 03/27/2014 09:01 PM, Thomas Bächler wrote:
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron:
Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=.
This means that we could replace the cron.* dropin scripts with systemd services and timers.
Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts
Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems
Affected packages:
community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8 /etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat
extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid
I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.
Finally! Yes I agree with this, I like the flexibility that it provides. Thanks. :) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 27/03/14 08:01 PM, Thomas Bächler wrote:
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron:
Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=.
This means that we could replace the cron.* dropin scripts with systemd services and timers.
Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts
Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems
Affected packages:
community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8 /etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat
extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid
I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.
I think it would make sense to remove cronie from base when these are migrated to timer units. It's not enabled by default, and ships with a setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point? I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue. -- Gaetan
On 27/03/14 10:01 PM, Gaetan Bisson wrote:
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point?
My point was only that the security risk is not theoretical. The only other arguments I have against including packages in base are disk and bandwidth usage and I don't think those are important when we're talking about such small numbers. Reducing the attack surface of most Arch installs is a stronger reason to keep base small. I think cutting down the number of setuid binaries shipped in base (and overall) would be great, and crontab is one of the few that we can't eventually switch to a significantly less scary capability like CAP_NET_RAW.
I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place.
Removing a daemon that's not enabled by default would help to streamline the base install too.
But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue.
I don't think systemd timers allow non-root users to run timer units outside of their session and the systemd session binary runs as non-root. AFAIK avoiding setuid binaries is one of the reasons for tools like hostnamectl using a client-server model.
[2014-03-27 22:59:36 -0400] Daniel Micay:
On 27/03/14 10:01 PM, Gaetan Bisson wrote:
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point?
My point was only that the security risk is not theoretical.
Of course it isn't: we all know every piece of software has bugs, which is a potential security issue when run as root. Now the above cronie bugs were fixed long ago. Do you have any evidence suggesting systemd should be less bug-prone than cronie?
AFAIK avoiding setuid binaries is one of the reasons for tools like hostnamectl using a client-server model.
Forgive me if I'm not convinced a user client giving commands to a root daemon is much better than a setuid binary implementing said commands. -- Gaetan
On 27/03/14 11:26 PM, Gaetan Bisson wrote:
My point was only that the security risk is not theoretical.
Of course it isn't: we all know every piece of software has bugs, which is a potential security issue when run as root. Now the above cronie bugs were fixed long ago. Do you have any evidence suggesting systemd should be less bug-prone than cronie?
Arch Linux is going to be shipping systemd in base, whether or not cronie is included. Including more setuid binaries increases the attack surface. I do think it can be assumed that including cronie (with the crontab setuid binary) and systemd will be more prone to exploitation than systemd alone. The importance of this is open to debate, but I think it's worth consideration, especially since cronie is not enabled by default. Perfect security is an unobtainable goal but we can do what we can to harden the base install. It means cron users will need to issue another pacman command, similar to how Arch leaving ptrace_scope enabled by default requires users of commands like `strace -p $PID`, `perf trace -p $PID`, `gdb -p $PID` or `reptyr $PID` to either turn it off or work around it. They're very minor inconveniences for a subset of Arch users and the security benefit is real, even if it's small.
On Fri, Mar 28, 2014 at 3:01 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point?
I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue.
I agree with Gaetan that I don't see the big security concern here. However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)? Cheers, Tom
On 28/03/14 06:01 PM, Tom Gundersen wrote:
On Fri, Mar 28, 2014 at 3:01 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point?
I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue.
I agree with Gaetan that I don't see the big security concern here.
However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)?
Cheers,
Tom
It's a very minor security concern, but I think it's a valid reason for having people who want it install it explicitly. It's not currently enabled by default, and will have a narrow use case when the existing packaged cron jobs on are. I don't think there will be a use case for a single user system anymore, or even *most* multi-user ones.
On 28/03/14 08:52 PM, Daniel Micay wrote:
It's not currently enabled by default, and will have a narrow use case when the existing cron jobs on are.
are gone*.
[2014-03-28 23:01:22 +0100] Tom Gundersen:
However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)?
Yes, I will be very happy to move cronie out of [core] and stop maintaining it. :) My disagreement was only with the security argument. Cheers. -- Gaetan
On Fri, Mar 28, 2014 at 1:01 AM, Thomas Bächler <thomas@archlinux.org>wrote:
Affected packages:
[...] community/snapper 0.2.1-1 /etc/cron.hourly/snapper
Next version of snapper will have the timer unit provided by upstream, so this package will get it anyway.
Am 28.03.2014 01:01, schrieb Thomas Bächler:
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats
After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.
On 03/28/2014 06:26 PM, Thomas Bächler wrote:
Am 28.03.2014 01:01, schrieb Thomas Bächler:
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats
After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.
Nice :) I guess for man-db should be better use tmpfiles instead of mkdir in the service unit. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 29.03.2014 01:31, schrieb Gerardo Exequiel Pozzi:
I guess for man-db should be better use tmpfiles instead of mkdir in the service unit.
The old cron.d script had the mkdir call inside with a comment that the directory should be recreated in case of deletion. I guess having it inside the service makes sure the service works even if someone rm -r's the directory at runtime. IMO mkdir should not be necessary at all, man-db should create the directory itself when needed.
On 03/29/2014 04:51 AM, Thomas Bächler wrote:
Am 29.03.2014 01:31, schrieb Gerardo Exequiel Pozzi:
I guess for man-db should be better use tmpfiles instead of mkdir in the service unit.
The old cron.d script had the mkdir call inside with a comment that the directory should be recreated in case of deletion. I guess having it inside the service makes sure the service works even if someone rm -r's the directory at runtime.
Yes, but the same things can happens for other directories on tmpfiles.d. Anyway, /var/cache/man is already define: $ grep cache /usr/lib/tmpfiles.d/systemd.conf d /var/cache/man - - - 30d
IMO mkdir should not be necessary at all, man-db should create the directory itself when needed.
Right. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 28.03.2014 22:26, schrieb Thomas Bächler:
Am 28.03.2014 01:01, schrieb Thomas Bächler:
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats
After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.
I am not sure how this interacts with suspend. My laptop was suspended at midnight, and on resume two of my timers fired, but 3 didn't. Maybe this is because interaction with suspend is broken, mabe because of AccuracySec set to 12h. I need to investigate this issue further.
Am 29.03.2014 08:52, schrieb Thomas Bächler:
Am 28.03.2014 22:26, schrieb Thomas Bächler:
Am 28.03.2014 01:01, schrieb Thomas Bächler:
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats
After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.
I am not sure how this interacts with suspend. My laptop was suspended at midnight, and on resume two of my timers fired, but 3 didn't. Maybe this is because interaction with suspend is broken, mabe because of AccuracySec set to 12h. I need to investigate this issue further.
*shrugs* Seems to work just fine now. All timers fired when I resumed at work today.
Am 01.04.2014 16:44, schrieb Thomas Bächler:
Am 29.03.2014 08:52, schrieb Thomas Bächler:
Am 28.03.2014 22:26, schrieb Thomas Bächler:
Am 28.03.2014 01:01, schrieb Thomas Bächler:
core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats
After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.
I am not sure how this interacts with suspend. My laptop was suspended at midnight, and on resume two of my timers fired, but 3 didn't. Maybe this is because interaction with suspend is broken, mabe because of AccuracySec set to 12h. I need to investigate this issue further.
*shrugs* Seems to work just fine now. All timers fired when I resumed at work today.
Okay, this should stay in testing for the moment. There's a case where the persistent timer *never* run until your machine is running just at the right moment. I prepared a patch for this problem, just need to test and submit it tonight. I also forgot to set the PACKAGER variable on this machine, so the packages have "Unkown packager", I should probably rebuild the packages soon, then.
participants (8)
-
Allan McRae
-
Andrea Scarpino
-
Daniel Micay
-
Gaetan Bisson
-
Gerardo Exequiel Pozzi
-
Massimiliano Torromeo
-
Thomas Bächler
-
Tom Gundersen