Proposed F19 Feature: systemd features

[Miloslav Trmač]

On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham <notting at redhat.com> wrote:
> In any case, to look at 'we have this functionality... now what':

For the sake of completeness, the default is 0) Avoid all the
arguments and work, and continue using existing files.

Is there actually a noticeable benefit in migrating?  We will help
Linux win neither on the desktop nor in the cloud by tinkering with
something admins are not supposed to touch :)

So far I can see:
A. Disk space usage in minimal systems has been mentioned: but cronie
is 200 kB, that's almost a waste of breath.
B. Cron's facility to submit jobs by unprivileged users to a daemon
running as root is a possible privilege escalation path; removing it
from the minimal (or even default) installation would remove a
possible risk (as long as we don't introduce an equivalent one as a
replacement.)
C. If we remove cron, is there anything left that needs the local MTA?
 Removing the local MTA would be similar to removing cron, only more
so.


B. and C. would be somewhat interesting - if and only if we did the
next step of making cron/MTA optional and not installed by default.
Is that reasonable and feasible?


> 3) introduce compatibility
>
> The cron and at interfaces aren't complex at all. It shouldn't be
> too hard to have a generator that reads crontab and cron.*, and
> the at queue, and creates the approprate timer files for systemd,
> in the same way that the fstab & sysv generators run. We could
> even have new versions of the crontab and at commands that do the
> right thing.
>
> That's extra work that would need to be done, and we would
> have to actually be obsoleting cron here (can't have two things
> running the same jobs),

Technically it's not necessary to obsolete cron as a tool/daemon (and
reimplement all of the functionality); systemd could be handling
/etc/cron.{hourly,daily,monthly,weekly}, leaving the full syntax of
/etc/{ana,}crontab and per-user task lists edited via crontab(1)
(including root's, which is distinct from /etc/crontab) to cronie.
Unfortunately there is an ugly half-way case: /etc/cron.d.

I'd be very hesitant about moving per-user jobs to systemd - for
security reasons the mechanism to accept user's job submission really
needs to be distinct from PID 1, so structurally it can't end up that
different from simply including cronie into systemd; an independent
cronie reimplementation would just be asking for privilege
escalations, with zero user benefit.
    Mirek