-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
pkg/bindings/images.nTar(): set ownership of build context to 0:0 #11473
pkg/bindings/images.nTar(): set ownership of build context to 0:0 #11473
Conversation
When attempting to run remote builds, users with UID/GID values that were high enough that they wouldn't be mapped into their default user namespace configurations would see their builds fail when the server attempted to extract the build contexts that they supplied, and failed to set ownership of the build context content to the UID/GID that were originally assigned to them. When archiving the build context at the client, set ownership of everything to 0:0, which we know is always mapped. Both ADD and COPY require that we set the ownership of newly-added content to 0:0 (unless the --chown flag is used), so throwing away the original ownership information doesn't hurt, anyway. As usual, tarballs that we extract as part of ADD aren't going to be affected. Signed-off-by: Nalin Dahyabhai <[email protected]>
LGTM |
This is a little scary, but it makes some sense. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nalind, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/hold cancel
When attempting to run remote builds, users with UID/GID values that were high enough that they wouldn't be mapped into their default user namespace configurations would see their builds fail when the server attempted to extract the build contexts that they supplied, and failed to set ownership of the build context content to the UID/GID that were originally assigned to them.
When archiving the build context at the client, set ownership of everything to 0:0, which we know is always mapped. Both ADD and COPY require that we set the ownership of newly-added content to 0:0 (unless the --chown flag is used), so throwing away the original ownership information doesn't hurt, anyway. As usual, tarballs that we extract as part of ADD aren't going to be affected.
Fixes #11474.