Support to start the container as non-root user

[ttionya]

Now the container cannot be started as a non-root user, because crond can only be started as root user.

Find ways to start crond as a non-root user, or find alternatives to crond, such as aptible/supercronic or gjcarneiro/yacron. Not limited to the above two.

In Development.

[kevdogg]

So I don't know a lot about Dockerfiles, however within the dockerfile, cant you initially install the required packages and start the required daemons and then create a user/group and then switch to that user?

[ttionya]

So I don't know a lot about Dockerfiles, however within the dockerfile, cant you initially install the required packages and start the required daemons and then create a user/group and then switch to that user?

The container is still started as root by default. But you can set - user: user:group in docker-compose.yml to specify the user and group to start the container.

[ttionya]

I've tried a lot to support start container as a non-root user. Next I explain the problems encountered.

The first problem is timezone. The backup tool symlinks the files in /usr/share/zoneinfo/ to the /etc/localtime based on the environment variable TIMEZONE when the container is started. It makes date and cron use the correct timezone. But the /etc directory is owned by the root user, so only the root user can write any files to it.

Of course there are other ways to solve this problem, a chain of symlinks, /etc/localtime -> /tmp/localtime -> /usr/share/zoneinfo/UTC, but the creation of the symlinks happens during the docker build phase, and the created /tmp/localtime is owned by root user, the non-root user at the time of starting the container cannot re-establish a symlink to /tmp/localtime. I haven't tried to establish the effect of invalid symlinks on date and cron.

The second is that BusyBox cron does not support non-root user to start, even with setcap. I found out that dcron can be started as a non-root user, but it hasn't been maintained for a long time, I prefer to use cronie if it supports non-root user start.

It was fatal that the output of the script could not be redirected to the stdout when using dcron, but the good news is that this problem has been solved, see dubiousjim/dcron#33.

The third issue, is directory permissions. We recommend mounting vaultwarden data volumes to /bitwarden/data/, but the owner of the /bitwarden directory is root, so non-root users cannot create other directories in /bitwarden, which is the working directory of the backup tool, and the wrong permissions will cause backup errors.

Since this is only a backup tool and will not be accessed externally, it was not considered to support non-root user to start the container, so the design of the directory did not consider the permission issue at all. But if we modify the directory now, it will cause break change.

I will look for other better solutions to support non-root users to start containers.