Repository navigation
[crond] ability to run cron jobs without root #113
Description
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).
Activity
robang74 commentedon Jul 11, 2026
Can you write a patch, please?
antoinetran commentedon Jul 13, 2026
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 commentedon Jul 15, 2026
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.
antoinetran commentedon Jul 16, 2026
So yes, sorry I wasn't clear. I meant I wanted to suggest implementing a simple patch which consist on integrating another cron implementation that is already container compatible: supercronic. I will try that, the patch is very simple and consist in wget the supercronic binary.
robang74 commentedon Jul 16, 2026
So far so well, we are trilled to see the patch and potentially integrating it.