[crond] ability to run cron jobs without root

[antoinetran]

Hi,

Current issue

In non-root policy environment in Kubernetes cluster (e.g.: OpenShift clusters), it is not possible to run containers as root. Thus cron container, especially packaged in the busybox tools, can not be run at all. Pragmatic related issue: nextcloud/helm#733

How to reproduce the issue

docker run -u 1234 --rm -ti alpine crond -f
crond[1]: crond (busybox 1.37.0) started, log level 8
crond[1]: root: Permission denied

Expected result

So cron usually needs root to be able to read all cron users crontabs. However, given that busybox tools are also largely used in container environment, and to follow non-root best practice, it would be great to have a non-root compatibility mode. This compatibility mode work such that there is no need for cron to have root privilege. For example, to run crond:

crond /tmp/crontab

would simply read the crontab and run it as the crond user (whether root or not). It will also ignore all the /etc/cron* and /var/spool/cron/crontabs/* files.
As a result this busybox cron would work in most sidecar container such as nextcloud use of crond (nextcloud/helm#733).

[robang74]

Can you write a patch, please?

[antoinetran]

Can you write a patch, please?

Hi, so I am not sure I can create a patch in a decent time, given my ability in C. However, how difficult is-it to integrate another cron implementation which is container-friendly, on top of the existing cron? This one https://github.com/aptible/supercronic, I have tested it in an OpenShift cluster with non-root restriction and it works pretty well. Although I am not an expert, the license is MIT. I can ask them if they are ok with being integrated, if this is ok for busybox maintainers.

[robang74]

Hi, so I am not sure I can create a patch in a decent time, given my ability in C. However, how difficult is-it to integrate another cron implementation which is container-friendly, on top of the existing cron?

You are free to propose every patch you like including adding stuff of featues and it will be accepted as long as the patch is going to work, it will not introduce regression, adding features would be optional in a way that they would not act as a regression compared with the current userbase (in particular embedded system deployment in production), and finally as long as you are able to maintain that stuff when bugfixes or regressions will pop up. Does it sound reasonable to you? Otherwise, it is better you find someone capable of such activities and pay for that work. In this specific case, it also a good practice that the person involved clarify the support that can offer and on which timeframe.