Allow docker container to start as non-root

[pbogre]

Discussed in #6

Since the entrypoint command makes use of gosu, running it as non-root will not work. The container should be able to be set to run as a normal user and still work.

[adepssimius]

Will need to update my sample chart when this is fixed. Let me know for testing, I have all of the test cases configured already.

[adepssimius]

Can I ask what was the purpose of gosu in the first place when running the standard command works just fine?

[pbogre]

gosu is useful in case the Docker container runs as root but the PUID/PGID environment variables specify another user, in which case gosu ${PUID}:${PGID} ... will run the command as that user. However I realize that I wasn't making the check for whether it was running as root to use gosu.

I have tried the following code in entrypoint.sh:

if [ $(id -u) -eq 0 ] && [ $(id -g) -eq 0 ];
then
    echo "Container running as root, setting permissions to ${PUID}:${PGID}..."
    chown -R ${PUID}:${PGID} ${DATA_PATH}
    gosu ${PUID}:${PGID} ${start_command}
else
    echo "Container running as $(id -u):$(id -g)..."
    ${start_command}
fi

And this should solve the problem in the case that the docker starts as non-root, for example by setting user: "1000:1000" in your docker-compose.yml.

This should also handle the case where the container starts as root (user isn't specified) by manually setting permissions, however this seems to fail when I try it. For instance I set the DATA_PATH folder permissions to 0:0, and set PUID=1000, PGID=1000 in the docker compose. However the chown command fails as it says it lacks permission for the change, which is strange as it's running as root.

Container running as root, setting permissions to 1000:1000...
jetlog-1  | chown: changing ownership of '/data': Permission denied

I'm not sure what's going wrong here. I will still push these changes (without the chown) as it should close this issue and you can test it, but I'll open a new one for this problem.

[pbogre]

If this commit solves this issue, feel free to close it

[adamzvolanek]

Updated the jetlog container (8/1) evening, would not start and errored out. Was not able to capture the error quick enough.

/mnt/user/appdata/internal/jetlog# ls -al
total 20756
drwxr-xr-x 1 root root       68 Jul 27 19:36 ./
drwxr-xr-x 1 root root       56 Jul 27 19:34 ../
-rwxr-xr-x 1 root root 19689472 Jul 27 19:34 airports.db*
-rwxr-xr-x 1 root root   610304 Jul 27 19:34 jetlog.db*
-rwxr-xr-x 1 root root   953403 Jul 27 19:34 world.geo.json*

Updating to chmod 777 shows the same symptoms.

The jetlog container will not start and is currently in a restart loop.

[pbogre]

Were you running the container as non-root? That is, specifying user: 1000:1000 or whatever IDs in your docker compose, or via other methods?

If not, your problem has more to do with #35.

If you did, then you should set proper file ownership by running the following command:

chown -R 1000:1000 /mnt/user/appdata/internal/jetlog

However since you mention you also ran chmod 777 and it didn't work (did you run it with -R on the whole directory), it may not be a permission issue. It would be useful if you managed to capture the error.

[adamzvolanek]

chown -R 1000:1000 /mnt/user/appdata/internal/jetlog

Editing my PUID and PGID seemed to have done the trick while still reducing to 755 permissions on the database files. I'm good with my issue.

[pbogre]

Cool, i'll close this issue since I was able to successfully start the container as non-root