-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Directory not writeable #41704
Comments
Hmm.. yes, I'm able to reproduce; DOCKER_BUILDKIT=0 docker build -t foo -<<EOF
FROM registry.fedoraproject.org/fedora:rawhide
RUN dnf -y update
RUN dnf -y install texlive
RUN ls -l /usr/share/texlive/
RUN whoami
RUN test -w /usr/share/texlive/texmf-config/
EOF Sending build context to Docker daemon 2.048kB
Step 1/6 : FROM registry.fedoraproject.org/fedora:rawhide
---> bbbdb33fe265
Step 2/6 : RUN dnf -y update
---> Using cache
---> 75fcdf5ab120
Step 3/6 : RUN dnf -y install texlive
---> Using cache
---> ae9a069847be
Step 4/6 : RUN ls -l /usr/share/texlive/
---> Using cache
---> 4b48054739ed
Step 5/6 : RUN whoami
---> Using cache
---> 66a18e2ace18
Step 6/6 : RUN test -w /usr/share/texlive/texmf-config/
---> Running in 4d69d51e2ef9
The command '/bin/sh -c test -w /usr/share/texlive/texmf-config/' returned a non-zero code: 1 Trying to run that failed container, the docker run --rm 66a18e2ace18 sh -c 'test -w /usr/share/texlive/texmf-config/; echo $?'
1 Interesting bit is that it's just the docker run --rm 66a18e2ace18 sh -c 'touch /usr/share/texlive/texmf-config/somefile && echo > /usr/share/texlive/texmf-config/some-other-file && ls -la /usr/share/texlive/texmf-config/'
total 20
drwxr-xr-x 1 root root 4096 Nov 23 09:55 .
drwxr-xr-x 1 root root 4096 Nov 23 09:27 ..
-rw-r--r-- 1 root root 1 Nov 23 09:55 some-other-file
-rw-r--r-- 1 root root 0 Nov 23 09:55 somefile
drwxr-xr-x 2 root root 4096 Nov 23 09:27 web2c The problem seems to be seccomp blocking a syscall; doing a docker run --rm --security-opt seccomp=unconfined 66a18e2ace18 sh -c 'test -w /usr/share/texlive/texmf-config/; echo $?'
0
bash or sh doesn't seem to make a difference, but is it possible that podman does not use seccomp by default? So question is; what syscall is |
@justincormack PTAL |
This is really strange, as the command fails, but if I
|
Ah interesting, if I run it with seccomp disabled, it behaves differently, loading locale files. That is really strange, something different must have happened earlier as it just makes a decision not to do this, without anything failing. |
The directory is created by installing Interestingly on the previous version of Fedora, F33, /cc @cverna |
I think this is the reason behind this issue --> faccessat() is broken when running under Docker So pretty much the a bug in glibc in Fedora rawhide |
Here is another, even simpler, case that fails for the same reason: FROM registry.fedoraproject.org/fedora:rawhide
RUN echo "echo test" > test.sh
RUN chmod +x test.sh
RUN ls -l test.sh
RUN test -x test.sh (log e.g. here: https://github.com/junghans/rawhide-latex/pull/2/checks?check_run_id=1480967204) |
I think this may be related to https://gitlab.alpinelinux.org/alpine/aports/-/issues/12321 -- musl-1.2.2 (part of alpine edge) now supports the |
The |
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]>
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Fixes moby#41704 The latest released versions of the static binaries (20.10.3) are still unable to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and related issues. The underlying cause seems to be that the build system here still uses the default version of libseccomp shipped with buster. An updated version is available in buster backports: https://packages.debian.org/buster-backports/libseccomp-dev Signed-off-by: Jeremy Huntwork <[email protected]> (cherry picked from commit 1600e85) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Just went down the same rabbit hole on Debian 10. Note that the |
For the full story see: https://bugzilla.redhat.com/show_bug.cgi?id=1897839
In short, a
Dockerfile
like:will fail, even though
/usr/share/texlive/texmf-config/
is owned byroot
.See https://github.com/junghans/rawhide-latex/runs/1439529976?check_suite_focus=true for example using
docker/[email protected]
, but I can reproduce this locally with Docker version 19.03.13, build 4484c46 (Fedora) and Docker version 19.03.13, build 4484c46d9d (OSX).The funny part is that
podman
anddocker
withbash
works as expected, but the defaultRUN
withsh
fails (see https://bugzilla.redhat.com/show_bug.cgi?id=1897839#c18).The text was updated successfully, but these errors were encountered: