Skip to content
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

make COPY copy as the set USER when using a Containerfile to build a container #5864

Open
jerabaul29 opened this issue Dec 4, 2024 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@jerabaul29
Copy link

Feature request description

For now, the following:

USER username
COPY file_on_host file_inside_container

results in file_inside_container to be owned by root:root. This feels inconsistent with the fact that USER is set. The workaround is to write:

COPY --chown=username:username file_on_host file_inside_container

which feels quite heavy / more error prone than just having a "context" set by USER.

Suggest potential solution

Would it be possible to consider changing the behavior of COPY, so that it follows the context set by the last preceding USER directive?

I.e. that:

USER username
COPY file_on_host file_inside_container

results in file_inside_container to be owned by username:username

?

Have you considered any alternatives?

For now the solution is:

COPY --chown=username:username file_on_host file_inside_container

but that feels ugly / heavy / error prone when after a USER directive one thinks commands happen as USER.

Additional context

No response

@jerabaul29 jerabaul29 added the kind/feature Categorizes issue or PR as related to a new feature. label Dec 4, 2024
@baude
Copy link
Member

baude commented Dec 5, 2024

Our build code comes from buildah so moving there.

@baude baude transferred this issue from containers/podman Dec 5, 2024
@nalind
Copy link
Member

nalind commented Dec 6, 2024

That's the long-documented behavior, and the COPY instruction provides a --chown flag for overriding that default. I don't expect to change the default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants