services.scheduling.fcron broken in 17.03

[alunduil]

Issue description

After upgrading to NixOS 17.03, I've found a small issue in the running of fcron. Jobs don't run if crontabs existed during a restart of fcron. This is due to ownership of the generated files in the fcron spool (should be root not fcron). This is due to the ownership change in the systemd unit in the fcron module. This permission change needs to be restricted to /var/spool/fcron/*.orig. I've verified this by changing the ownership of the appropriate files (those not ending in orig) to root:root and fcron loads the jobs upon start.

Steps to reproduce

1. Use NixOS 17.03
2. Enable fcron (services.scheduling.fcron.enable = true)
3. Use fcrontab -e to create a crontab
4. Restart fcron (systemctl restart fcron)
5. Check that the jobs are not scheduled to run (fcrondyn -x ls)

journalctl contains the following statements:

Apr 10 21:37:57 elijah.laptops.alunduil.com fcron[6281]: Non-new file alunduil owned by someone else than root

Technical details

• System: 17.03.928.69d9061908 (Gorilla)
• Nix version: nix-env (Nix) 1.11.8
• Nixpkgs version: 17.03.928.69d9061908

[Mic92]

You mean something like this:

systemd.services.fcron.preStart = ``
  install \
    --mode 0770 \
    --owner fcron \
    --group fcron \
    --directory /var/spool/fcron
  for f in /var/spool/fcron/*.orig; do
    chgrp fcron "$f"
  done
``

would fix your problem?

[alunduil]

Yes, but now that I'm seeing it run. I'm thinking just dropping the change in ownership is the best path. It appears that the fcron daemon runs as root and expects those files to be owned by root. I just created a new file and the permissions were set like so:

-rw------- 1 root  root  714 Apr 11 09:00 systab
-rw------- 1 root  fcron 459 Apr 11 09:00 systab.orig

This indicates that setting the owner of /var/spool/fcron with your proposed install command will be fine but the loop doesn't seem strictly necessary. It would ensure that the permissions remain what is expected but fcron will also ensure that is the case.

Why do you do the group change with a loop instead of chgrp fcron "/var/spool/fcron/*.orig"?

[Mic92]

I dropped chmod in 5ca7e8a

[alunduil]

Thanks @Mic92! What's the usual time before I'll see that show up in the stable packages?

[Mic92]

It should be already.

[alunduil]

Looks like the install command is now causing problems on newly activated fcrons:

May 03 20:02:34 mycroft systemd[1]: Starting fcron daemon...
May 03 20:02:34 mycroft fcrontab[2900]: Could not chdir to /var/spool/fcron: Permission denied
May 03 20:02:34 mycroft fcron-pre-start[2883]: 2017-05-03 20:02:34 ERROR Could not chdir to /var/spool/fcron: Permission denied
May 03 20:02:34 mycroft systemd[1]: fcron.service: Control process exited, code=exited status=1
May 03 20:02:34 mycroft systemd[1]: Failed to start fcron daemon.
May 03 20:02:34 mycroft systemd[1]: fcron.service: Unit entered failed state.
May 03 20:02:34 mycroft systemd[1]: fcron.service: Failed with result 'exit-code'.

The permissions on /var/spool/fcron:

[root@mycroft:~]# ls -la /var/spool/fcron
total 8
drwxrwx--- 2 fcron fcron 4096 May  3 20:00 .
drwx------ 4 root  root  4096 May  3 20:00 ..

Looks like the install command needs to set the s bits for user and group. Permissions on a working fcron:

giskard ~ # ls -la /var/spool/fcron
total 24
drwsrws---  2 fcron fcron 4096 May  3 20:11 .
drwxr-xr-x 12 root  root  4096 Oct  6  2012 ..
-rw-r--r--  1 root  root     0 Jan 14 20:05 .keep_sys-process_fcron-0
-rw-------  1 root  root  1852 May  3 20:11 alunduil
-rw-r-----  1 fcron fcron 1394 Jan  3  2015 alunduil.orig
-rw-------  1 root  root   821 May  3 20:11 systab
-rw-------  1 root  fcron 1842 Jan 14 20:07 systab.orig

Looks like the install should be using 6770 for mode to truly fix this.