Dockerfiles: run tar x with --no-same-owner #167
Conversation
When we're extracting tar archives, always use --no-same-owner, so that ownership doesn't get set to oddball values that might have been used by the builder. Signed-off-by: Nalin Dahyabhai <[email protected]>
|
This looks sane to me upon quick inspection. Letting the CI tests run |
|
I also wonder if this is the root cause of eclipse-che/che#22799 @nalind have you pushed the resulting image build from your changes anywhere? I'd like to quickly test something :) |
Yes, this should prevent that error when pulling the image. There's a subtle bug in how we handle parsing for heredocs in
I've pushed it to quay.io/nalind/testing:udi. Thanks! |
|
@nalind thank you SO much, I was really puzzled by this bug. Your fix looks good to me :) |
|
Thanks! containers/buildah#5473 aims to fix the other problem. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: AObuchow, nalind, svor The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
When we're extracting tar archives, always use --no-same-owner, so that ownership doesn't get set to oddball values that might have been used by the creator of those tar archives.
I'm running podman as an unprivileged user, and the default configuration can't build or pull images with content ownership UIDs or GIDs above 65536 or so. Examples that I ran into in quay.io/devfile/universal-developer-image@sha256:2364d29270cdeadb15042785411900776a0b57dadc352befcff547242dfd8eb1 include /usr/local/bin/LICENSE (301071:301071) and /usr/local/bin/tkn (in two layers, one owned by 301071:64025, the other by 0:1000640000).
With this change applied, I can pull the built image without triggering an error.