Repository navigation
Make cron.php be executed by UID provided at startup. #1740
Description
Expectation:
Cron should execute cron.php with the UID the container is started with (in case a UID is provided).
Status Quo:
Cron.php is executed with www-data, which is UID 33 / 34 (depends on distribution) in the container.
Result: Cron fails to execute cron.php withe the appropriate user.
Details:
Due to security reasons, I am running all my containers rootless and with seperated user accounts. I think rootless non-root execution will be the future of containerization anyways.
I utilize user 1008 for nextcloud.
Nextcloud recognizes this fact and reminds the user that cron is to be executed by the same user in the web interface:
Use system cron service to call the cron.php file every 5 minutes. The cron.php needs to be executed by the system user "1008".Therefore, I want to start the cron container with the same UID as the app:
$ podman run -d \
--name=nextcloud-cron \
--pod=nextcloud \
--restart unless-stopped \
--runtime crun \
--user 1008:1008 \
-v ~/nc/html:/var/www/html:z \
-v ~/nc/data:/var/www/data:z \
--cap-add=CAP_NET_BIND_SERVICE \
--cap-add=CAP_SETGID \
--cap-add=CAP_SETUID \
--entrypoint=/cron.sh \
docker.io/library/nextcloud:latestThe containers works, file access is fine for UID 1008 - however, the execution of cron.php fails:
crond: USER www-data pid 4 cmd php -f /var/www/html/cron.php
Could not open input file: /var/www/html/cron.phpNevermind, as "www-data" would be UID 33 and not the appropriate user anyways (should be 1008, as announced by nextcloud). File access for UID 1008 is working fine though.
If I change the UID of www-data in passwd to the designated UID 1008 and passthrough the passwd to the container, the execution fails:
Passwd line:
www-data:x:1008:33:www-data:/var/www:/usr/sbin/nologinAdditional passthrough of passwd for the start of podman:
-v ~/nc/passwd:/etc/passwd:ro \Output of the cron-log:
crond: USER www-data pid 2 cmd php -f /var/www/html/cron.php
This account is currently not available.There is a solution, but it is crap: The execution of cron-php via host works fine:
$ podman exec --user 1008 -t nextcloud-cron php -f /var/www/html/cron.phpDesperate users could execute this line via crond of the host but hopefully you agree that this is not what we want to see ;)
Activity
J0WI commentedon Apr 28, 2022
This might be a duplicate of #359
vicky-bs commentedon May 11, 2022
I have a similar issue and I have tried different images, removed and reinstalled multiple times and cron doesn't run as it's supposed to. Here are the details of my setup (please excused me as I'm new to self hosting but have spent huge number of hours trying to solve this issue)
OS - Windows
Distro - WSL2 kernel and Ubuntu
Nextcloud - Latest version with mariadb and redis
Issue - Selecting Cron in setting doesn't do anything
Solutions tried -
I'm finally reaching out here to see if anyone could help
Thanks,
SaswatPadhi commentedon Nov 9, 2022
@J0WI: #359 fixes the UID/GID issue with apache (in the "app" container), but the "cron" container that runs the cron jobs, the user is hard coded as
www-data:docker/Dockerfile-alpine.template
Lines 10 to 11 in 6e7695e
So what ends up happening is,
apacheruns as a non-root user as per the UID:GID, butcronruns aswww-dataand fails repeatedly with permission errors.@Moltey: I have implemented another solution:
I override the
cron.shto change thewww-datahardcoding:then I mount it (read-only) within my "app" container, and pass the appropriate
APACHE_UIDto my "cron" container:That's the key idea, but I implemented a couple of other hacks to be able to edit the crontab file directly from the host -- it's reloaded automatically in the "cron" container.
@J0WI: I think the app (not cron) entrypoint should create a new user with the UID:GID and add move the cron job (from
www-data) to that user. Then the cron container would work as expected without any additional hacksJ0WI commentedon Nov 25, 2022
I tried to move a simple
echo "*/5 * * * * php -f /var/www/html/cron.php" | busybox crontab -script to thecron.shentrypoint itself, but unfortunately busybox does not allow to runcrontabas non-root: https://git.busybox.net/busybox/tree/miscutils/crontab.c?h=1_35_stable#n110SaswatPadhi commentedon Nov 25, 2022
Yes, busybox requires
crondto run as root.The current entrypoint script does run it as root. The problem is just that the crontab file (at
/var/spool/cron/crontabs) is under the wrong user (www-data). When the nextcloud container runs with a non-root UID (using--user), the crontab file should actually be renamed to that user's name in place ofwww-data, to avoid permission issues.As you have noticed, it's currently not possible to run the cron container as a non-root user, although nextcloud container can run as a non-root user. Currently, even when the cron container is run as root, the cron jobs fail with permission errors.
As for security, the cron container only runs the
crondprocess as root. The actual cron tasks (php) are run with the respective user's UID, which iswww-datacurrently.J0WI commentedon Nov 26, 2022
At this point, I think it's easier to just run your own
docker run -v my_nextcloud:/var/www/html --user my_user nextcloud:fpm-alpine sh -c 'while true; do php -f /var/www/html/cron.php; sleep 5m; done'. Or, as already mentioned above, just use a timer on your host that runsdocker exec ....There is no trivial way to run the cron script as non-root and detect whatever user is used in the other container.
SaswatPadhi commentedon Nov 26, 2022
The bug report is about making
cron.phpbe executed by the right UID, notcrond.I think you are mixing up the cron daemon with cron scripts (or crontabs).
False. They (
var/spool/cron/crontabs/www-data) already do, just as the wrong user.J0WI commentedon Nov 26, 2022
If you run the cron container as root, it can run
crondand managecrontabsfor all users. However, the cron container has no knowledge of the user that runs in the other PHP container. You have to specify the user. The above example executescron.phpasmy_user.Moltey commentedon Nov 27, 2022
Can we please agree that this is a very nasty workaround? 😄
I ended up calling cron.php via the crontab of the host machine which is not satisfying, neither.
IMHO, this is a design issue you might want to consider in one of the next major releases.
J0WI commentedon Feb 8, 2023
This is somewhat covered in #1901
SaswatPadhi commentedon Feb 9, 2023
Running
crond(the daemon) as non-root and running thecron.phpfile (the cron job) as non-root are two different things.remus-selea commentedon Apr 8, 2023
I attempted to use the nextcloud cron container, but it didn't work as described in this issue. The container was configured to run as a non-root user using the user option with a specific UID and GID, but the cronjob failed. I believe it is not worth using it as it needs to run as root. Running containers as root is generally not recommended due to security reasons.
I decided to set up a cronjob on my LXC host. I added a cronjob for a non-root user who is also not part of the sudo group, to run the cron script inside the nextcloud container using docker exec.
To check that the cronjob ran successfully, I searched the syslog for the cron script using this command:
This solution will work for me until Nextcloud decides to address the issue.
chylex commentedon Jun 17, 2023
I ended up building a custom image with supercronic, couldn't get crond to work as non-root either.
IceflowRE commentedon Jul 28, 2024
To summarize this, it is currently impossible to run the docker container as a different user?