uid for user inside container
lars-solberg opened this issue · 7 comments
Is your feature request related to a problem? Please describe.
When using unblob in a container, I need to rebuild the image because of uid missmatches.
Describe the solution you'd like
A way to specify uid when starting the container. Example --user=1001. This currently doesnt work since the unblob binary is inside the home-directory of unblob with strict permissions.
Something like this makes a new image that works.
FROM ghcr.io/onekey-sec/unblob:24.9.30
USER root
RUN usermod --uid 1001 unblob
USER unblob
There are multiple ways of solving this.
- Replacing the entrypoint that runs the usermod command above based on the current uid. Then execute "unblob"
- Package the binary in a location that is available for all users in the container. Example /usr/local/bin
Describe alternatives you've considered
Continue rebuilding the image, even tho thats not a good solution.
Additional context
The files I am scanning is part of a bigger pipeline where files are changed by multiple other images. The uid of the files needs to match up.
For a temporary workaround for other people in the same situation is to run it as root for now with PATH env HOME.
--user=0 -e PATH=/home/unblob/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games -e HOME=/home/unblob
Why can't you simply chmod the files you want to unblob before running the container, so unblob in the container have access to them? What's your exact use case?
Why can't you simply chmod the files you want to unblob before running the container, so unblob in the container have access to them? What's your exact use case?
Yes, that is possible. But since this is only one small step of many in a pipeline where I create, change and read the files it is a pain to change the uid back and forth to what the current step can read. I'm also trying to do this with as little permissions for each container as possible.
Having a way to specify the uid would make unblob easier to use in many situations. Everything from ad-hoc runs to pipelines with multiple file-handlers.
Making unblob available to all users is rather simple:
diff --git a/Dockerfile b/Dockerfile
index f93323f..ddd7bba 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -9,12 +9,10 @@ WORKDIR /data/output
COPY unblob/install-deps.sh /
RUN sh -xeu /install-deps.sh
-USER unblob
-ENV PATH="/home/unblob/.local/bin:${PATH}"
-
# You MUST do a poetry build before to have the wheel to copy & install here (CI action will do this when building)
COPY dist/*.whl /tmp/
RUN pip --disable-pip-version-check install --upgrade pip
-RUN pip install /tmp/unblob*.whl
+RUN pip install /tmp/unblob*.whl --prefix /usr/local
+USER unblob
ENTRYPOINT ["unblob"]I don't see issues with this approach since it will be containerized anyway and unblob will still run unprivileged within the container.
That is much cleaner.. Makes me wonder if there was an original reason for having the PATH and .local/bin build-path? Looks like it's always been like that (3+ years), so it was probably just by random from the first image
You can pull the latest Docker image, let us know if this works for you!
Perfect! This worked!
Had worked around this for over a year... Finally creating an issue and it was solved in 2 hours.. 😆
Awesome guys!