Hello!
This is likely related to #123.
In my case, Podman with krun runtime is used as a lightweight isolated environment for running untrusted workloads, with the assumption that building this environment may also include running untrusted commands, hence the desire to use krun early on for podman create.
Running podman build . in a directory that only contains the following Containerfile:
FROM fedora-minimal
RUN useradd user
USER user
RUN id
results in the following output:
STEP 1/4: FROM fedora-minimal
STEP 2/4: RUN useradd user
--> d622c70483e6
STEP 3/4: USER user
--> 2d2f08c4c03c
STEP 4/4: RUN id
uid=0(root) gid=0(root) groups=0(root)
COMMIT
--> 7054ae1b138f
7054ae1b138fbf5313eb8e5d0d2df61e00e75b67ca4ac65749e4230a36630c6b
In the meantime, I tried the following workaround: drop everything that I want executed as an unprivileged user during container build time to an executable file test.sh, and go with the following Containerfile:
FROM fedora-minimal
COPY test.sh /
RUN useradd user &&\
dnf -y install setpriv &&\
setpriv --reuid=1000 --regid=1000 --init-groups --reset-env /test.sh
This seems to result in the expected output from id inside the script:
uid=1000(user) gid=1000(user) groups=1000(user)
I wonder if this workaround is safe to use?
Thank you!
Hello!
This is likely related to #123.
In my case, Podman with
krunruntime is used as a lightweight isolated environment for running untrusted workloads, with the assumption that building this environment may also include running untrusted commands, hence the desire to usekrunearly on forpodman create.Running
podman build .in a directory that only contains the followingContainerfile:results in the following output:
In the meantime, I tried the following workaround: drop everything that I want executed as an unprivileged user during container build time to an executable file
test.sh, and go with the followingContainerfile:This seems to result in the expected output from
idinside the script:I wonder if this workaround is safe to use?
Thank you!