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

Ensure WORKDIR from images is created #7176

Merged
merged 2 commits into from
Aug 5, 2020

Conversation

mheon
Copy link
Member

@mheon mheon commented Jul 31, 2020

A recent crun change stopped the creation of the container's working directory if it does not exist. This is arguably correct for user-specified directories, to protect against typos; it is definitely not correct for image WORKDIR, where the image author definitely intended for the directory to be used.

This makes Podman create the working directory and chown it to container root, if it does not already exist, and only if it was specified by an image, not the user.

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 31, 2020
@mheon
Copy link
Member Author

mheon commented Jul 31, 2020

@giuseppe PTAL

@mheon
Copy link
Member Author

mheon commented Jul 31, 2020

(This PR also includes a large swath of comment updates to fields in Container, because the lack of descriptiveness annoyed me)

@mheon mheon force-pushed the make_entrypoint branch from 2bc24e6 to 3803fe2 Compare July 31, 2020 21:26
Comment on lines 248 to 250
if len(newEntry) > 0 {
options = append(options, libpod.WithCreateWorkingDir())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we look at img.WorkingDir(...)? Why does it depend on the entrypoint?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, fixed

@rhatdan
Copy link
Member

rhatdan commented Aug 1, 2020

Does the owner of the WORKDIR depend on the user of the image or the root of the image?

cat Containerfile
from fedora
run useradd dwalsh
user dwalsh
workdir /home/dwalsh

Is work dir supposed to be owned by dwalsh, or by root?

@mheon
Copy link
Member Author

mheon commented Aug 1, 2020

In Docker, it's always owned by root.

A recent crun change stopped the creation of the container's
working directory if it does not exist. This is arguably correct
for user-specified directories, to protect against typos; it is
definitely not correct for image WORKDIR, where the image author
definitely intended for the directory to be used.

This makes Podman create the working directory and chown it to
container root, if it does not already exist, and only if it was
specified by an image, not the user.

Signed-off-by: Matthew Heon <[email protected]>
@mheon mheon force-pushed the make_entrypoint branch from 3803fe2 to 333d9af Compare August 3, 2020 18:45
@TomSweeneyRedHat
Copy link
Member

LGTM
assuming happy tests

@rhatdan
Copy link
Member

rhatdan commented Aug 3, 2020

/lgtm
/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 3, 2020
@openshift-ci-robot openshift-ci-robot added lgtm Indicates that a PR is ready to be merged. and removed lgtm Indicates that a PR is ready to be merged. labels Aug 3, 2020
@mheon
Copy link
Member Author

mheon commented Aug 4, 2020

Image in the E2E test from a podman build isn't being picked up by subsequent podman run - trying to debug now.

Signed-off-by: Matthew Heon <[email protected]>
@mheon mheon force-pushed the make_entrypoint branch from b37e8aa to 21421c8 Compare August 4, 2020 20:22
@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mheon

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mheon
Copy link
Member Author

mheon commented Aug 4, 2020

The problem appears to be with remote - all the tests that build images are SkipIfRemote. I made this one SkipIfRemote as well.

@giuseppe
Copy link
Member

giuseppe commented Aug 5, 2020

LGTM

@rhatdan
Copy link
Member

rhatdan commented Aug 5, 2020

/lgtm
/hold cancel

@openshift-ci-robot openshift-ci-robot added lgtm Indicates that a PR is ready to be merged. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Aug 5, 2020
@openshift-merge-robot openshift-merge-robot merged commit d1aaf33 into containers:master Aug 5, 2020
@vrothberg
Copy link
Member

We merged a rather exotic commit message (going through commits atm)

@mheon
Copy link
Member Author

mheon commented Aug 11, 2020

Yeah, that one was my fault... I made a debug commit to figure out why the tests were failing, and when I fixed it I did a git commit -a --amend --no-edit to bring the changes it, completely forgetting that I have a debug commit on top...

The good news is that the actual things that should not be merged were wiped out by that git commit --amend.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 24, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants