New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Dockerfile to let the app run without root permissions #200
Conversation
Hello, Thanks for your contribution! It looks just right, I just have a little reservation about the change: does it require users to update the database's rights before upgrading? Cheers, |
Hi, That is a good catch! Yes, this should considered as a breaking change. Since the current database file is owned by
Rollback should not be an issue since the app is running as |
Okay, I'll have to find a way to inform users (which may not even know that this repository exists) of this breaking change 🤔 |
I did the following test:
The container/app starts, but when clicking on
A few ideas:
|
I think I'll check permissions on the database at startup, print a message explaining the issue with remediation steps and then exit. I will then look into merging this. |
Hello, I have been trying to test the lack of permissions after upgrading on my laptop with Docker, both in normal and rootless mode but I wasn't able to reproduce the issue after building the latest commit locally, is it an issue only on Podman? |
Hi Axel, Hmm, that's interesting. Did you use your local built version? I don't see a new tag on DockerHub since the merge. I approached the problem from Linux permissions: First the database file was owned by root (0) since the app/container was running under root. After the update it was running under user default (1001). Since the file was created to only be writable by the user. That should be enough to get a write permission error. Or maby Docker does some checks and applies some ownership magic before starting the container? |
I built it locally, yes (I disabled the CI on the main branch since I wasn't able to stop it from pushing on PR runs). Okay, so I was testing on another machine and I realized that the ORM wasn't trying to write to the database until I create or update a game... I'll have to devise another way to detect if the database is writable. |
I created an script which can be enhanced / simplified: #!/usr/bin/env python3
import os
import sys
# Get current process user and group
current_user_id = os.getuid()
current_group_id = os.getgid()
print(f"Current UID: {current_user_id}")
print(f"Current GID: {current_group_id}")
# Define file path
file_path = '~/Podmandata/poker/database.db'
# Expand home directory in the file path using os.path.expanduser()
expanded_file_path = os.path.expanduser(file_path)
# Get file permissions using os.stat()
file_stats = os.stat(expanded_file_path)
owner = file_stats.st_uid
group = file_stats.st_gid
print(f"File owner: {owner}")
print(f"File group: {group}")
try:
f = open(expanded_file_path, "a")
print("The file is writeable for the current user")
except PermissionError:
print("The file is not writeable!")
sys.exit(1) Testing:
|
Thanks for your code, I figured what I got wrong: I was expecting an |
Well, I may have spoken too soon: my code now detects when
|
And what is the output when you listing the
|
I don't get it... |
And the output of:
|
|
And the permissions of the /data directory?
|
The issue comes from the folder's permissions... Extremely weird behavior from Python. I'll update the check and instructions accordingly. |
I also seem to have an issue with Podman with the new version. It is all good when not mounting a folder. But when I do the |
Hum, I haven't checked with folder mounts either. Let me know what you find on your side. |
So, I came to the conclusion that supporting all platforms is not easy ;). For Podman I found that you can use the
Update: The option above works for Podman on Linux for Podman on macOS (via Podman machine) you can use the
For Docker there is no such option, there is an issue from 2013 to support this[2]. The current "workaround" is to chown the directory on the host before starting the container:
I did not test it with rootless Docker since the Docker in Docker rootless container would not start. But in the logs I saw that the same mechanism is used as with Podman (mapping of UID/GID. But since Docker doesn't have the
To summarize, before this PR the app/container would run fine with Docker, Podman and K8s where you are allowed to run privileged containers. [1] https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-volume-host-dir-container-dir-options |
Hello,
In this pull request the the Dockerfile is updated mainly to let the app/container run rootless.
This is handy if you want to run the app/container in a environment when running as root is not allowed.
For example a Kubernetes platform with Restricted Pod Security Standards[1] / Security Context[2]
There is also a modification to support arbitrary user ids [3].
Also the
/data
directory is created during the build with the correct permissions. This makes the-v planning-poker-data:/data
option optional.Finally the full registry path is used at the
FROM
instructions to clarify where the image comes from.[1] Pod security standards
[2] Security Context
[3] Support arbitrary user ids