Open IceCodeNew opened 5 months ago
IceCodeNew
commented
3 months ago Hi @tonistiigi ,
I apologize for the interruption, but I wanted to bring to your attention that this proposal seems to have stalled due to the lack of an assignee.
Would you be able to refer someone who could provide direction on which solution we should proceed with?
Thank you for your time and assistance.
polarathene
commented
3 months ago UPDATE: I've covered this concern with a few other related issues over at: https://github.com/docker/docs/issues/20660
I won't have time to contribute proper docs improvements myself, but if you do tackle that please update the linked issue with your related PR for traceability :)
the newly deployed image could not work properly because the ownership of
/home/nonroot/becameroot:root
This --link quirk only seems to affect docker-container driver. I agree it should be documented for clarity, in the meantime I've done so unofficially here.
You can avoid this problem by using the docker driver (docker buildx build --builder default ...), or by adjusting your Dockerfile to use COPY --link --chmod=null workaround.
NOTE: I'm not 100% sure if --link functionality is still applied, or if either solution triggers --link=false. Is there an easy way to verify locally?
# syntax=docker.io/docker/dockerfile:1
# `src` has parent dirs with permissions and ownership: `777 100:100`
FROM alpine AS src
WORKDIR /foo/bar/baz
RUN <<HEREDOC
touch a b c
chown -R 100:100 /foo
chmod -R 777 /foo
HEREDOC
# `dest` has parent dirs with permissions and ownership: `770 200:200`
FROM alpine AS dest
RUN <<HEREDOC
mkdir -p /foo/bar/baz
chown -R 200:200 /foo
chmod -R 770 /foo
HEREDOC
# Workaround to prevent modifying ownership and permissions of an existing COPY target path segments:
# NOTE: `--chmod` can use any invalid value to prevent the caveat of `--link` + `docker-container` builder driver.
FROM dest AS link-workaround-fix
COPY --link --chmod=null --from=src /foo/bar/baz /foo/bar/baz
# `eza` is a fancier `ls` command. Used here for better visualizing changes:
RUN apk --no-cache add eza
CMD eza -lanhog --tree --no-time --no-filesize --no-permissions /foodocker buildx build --load --tag bug-copy-link .
docker run --rm -it bug-copy-linkYou'll get this output from the eza CMD:
Whereas without the --chmod workaround, as experienced the target path ownership and permissions are modified to 755 0:0:
NOTE:
COPY --link, permissions will be defaulted to 755 and --chmod has no effect on that. Meanwhile --chown will override the default root:root ownership.COPY permissions/ownership from the src path parents, you would need to copy those over, not just the contents from the src path (such as /foo/bar /foo/bar would copy over baz/ with src ownership/permissions).That last one if important to you may be problematic due to sibling content also getting copied over, you could use --parents or --exclude to workaround that:
# syntax=docker/dockerfile:1.7-labs
# ...
# Preserve `baz/` ownership/permissions from src via --parents `./` syntax:
COPY --link --chmod=null --from=src --parents /foo/bar/./baz /foo/bar
# Preserve `bar/baz/` ownership/permissions from src via --exclude filter on src `/foo` dir
# NOTE: There is no negative match pattern like `!` for a substring supported, thus you must explicitly ignore all unwanted dirs
COPY --link --chmod=null --from=src --exclude=/foo/dont-copy-me /foo /foo
Situation:
Amended the
COPYinstruction with--linkto make better usage of the build cache, and unexpectedly introduced a file permission problem.I copied the directory
/home/nonroot/of a builder stage to the rootless final stage. And found out that the newly deployed image could not work properly because the ownership of/home/nonroot/becameroot:rootHow to reproduce:
Discussion:
Please note that the ownership of
/home/nonroot/is#8 0.065 drwx------ 1 nonroot nonroot 8 May 29 15:01 ./while the ownership of
/emptydir/home/nonroot/in the final stage is#11 0.065 drwxr-xr-x 1 root root 8 May 29 15:01 ./Since the
COPY --linkbasically works likeI guess it makes sense for the unexpected ownership change of
/home/nonroot/I am not proposing to change the quirk of
COPY --link, instead I think it is important for people to notice such a discrepancy of behavior among the instructionsCOPY© --link.Solution:
COPY --link, with the limitation of only numeric UID/GID could work ( #2987 ). This idea may not be preferred if the UID/GID of the previous stage is prone to changes.I am willing to contribute to the docs should this proposal be accepted. Before that, I would like to know if changes to the code or other actions are preferred.