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 the consistent setting of the HOME env variable on container start #18492

Merged
merged 1 commit into from
May 10, 2023

Conversation

daw1012345
Copy link
Contributor

Does this PR introduce a user-facing change?

Fixes an issue where the HOME environment variable would be configured inconsistently between container starts if a new passwd entry had to be created for the container

Description

Podman sets the HOME environment variable to the home directory of the user executing the podman command (if it is mounted) only if a new passwd entry has to be added on start. After a container restart, HOME is set to the home directory of the user configured with the --user flag.

Reproduction/Example

Screenshot from 2023-05-05 21-39-36

Impact

This impacts tools such as VSCode Dev Containers as they use this variable to decide where to place files (the vscode server in this case). This issue is particularly annoying for people using Dev Containers and toolbox as a restart causes VSCode to place the server in a different place, often /root where it does not have write permissions.

Solution

Set the HOME env variable on container creation, prioritized in the following order:

  1. Existing HOME env variable
  2. Home folder of the user executing the podman command
  3. Home folder of the user specified with the --user flag

@daw1012345 daw1012345 force-pushed the main branch 4 times, most recently from 815d3ce to fd72b13 Compare May 6, 2023 08:27
@rhatdan
Copy link
Member

rhatdan commented May 6, 2023

@n1hility @vrothberg @containers/podman-maintainers PTAL

@giuseppe
Copy link
Member

giuseppe commented May 8, 2023

I don't think we want to honor the home folder of the user executing the command. The order should be:

  1. Existing HOME env variable
  2. Home folder of the user specified with the --user flag

The issue with using the current user home directory is that the same command would have different behaviors on different machines. If you want to override the home directory, just specify it on the command line

Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

I agree with @giuseppe, it doesn't seem to make sense to set the home based on the user executing the command.

This seems to be a simple bug when the container is created with --userns keep-id -v $HOME:$HOME --user 0:0 so I think we should just fix that.

test/e2e/start_test.go Outdated Show resolved Hide resolved
test/e2e/start_test.go Show resolved Hide resolved
test/e2e/start_test.go Outdated Show resolved Hide resolved
test/e2e/start_test.go Outdated Show resolved Hide resolved
test/e2e/start_test.go Show resolved Hide resolved
libpod/container_internal_common.go Outdated Show resolved Hide resolved
@daw1012345
Copy link
Contributor Author

The issue with using the current user home directory is that the same command would have different behaviors on different machines. If you want to override the home directory, just specify it on the command line

This indeed makes more sense. I've adjusted the PR to reflect this - the home directory of the caller is no longer considered.

@daw1012345 daw1012345 requested a review from Luap99 May 9, 2023 07:12
return execUser.Home, nil
}

// Ensure HOME is not already set in Env
Copy link
Member

Choose a reason for hiding this comment

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

does it make sense to move this and the stanza below "up"?

@@ -2432,6 +2426,46 @@ func (c *Container) generateCurrentUserPasswdEntry() (string, int, int, error) {
return pwd, uid, rootless.GetRootlessGID(), nil
}

// Sets the HOME Env variable with precedence: caller home, execUser home
func (c *Container) setHomeEnvIfNeeded() error {
Copy link
Member

Choose a reason for hiding this comment

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

if this is only used once, can it just be inline?

Copy link
Member

Choose a reason for hiding this comment

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

I think a separate function is better.

@baude
Copy link
Member

baude commented May 9, 2023

/approve

LGTM, small nits identified

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 9, 2023
libpod/container_internal_common.go Outdated Show resolved Hide resolved
@@ -2432,6 +2426,46 @@ func (c *Container) generateCurrentUserPasswdEntry() (string, int, int, error) {
return pwd, uid, rootless.GetRootlessGID(), nil
}

// Sets the HOME Env variable with precedence: caller home, execUser home
func (c *Container) setHomeEnvIfNeeded() error {
Copy link
Member

Choose a reason for hiding this comment

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

I think a separate function is better.

…tart

Signed-off-by: Dawid Kulikowski <git@dawidkulikowski.pl>
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 10, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 10, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude, daw1012345, Luap99

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

@openshift-merge-robot openshift-merge-robot merged commit 7a5daa0 into containers:main May 10, 2023
@debarshiray
Copy link
Member

Kudos for adding the tests, @daw1012345 !

@debarshiray
Copy link
Member

debarshiray commented Jun 27, 2023

I arrived here from containers/toolbox#1296 Since this pull request explicitly mentions Toolbx, I thought that I would leave my doubt here as well for the sake of my future self and anybody else who might be following along.

Set the HOME env variable on container creation, prioritized in the
following order:

Existing HOME env variable
Home folder of the user executing the podman command
Home folder of the user specified with the --user flag

I don't think we want to honor the home folder of the user executing
the command. The order should be:

Existing HOME env variable
Home folder of the user specified with the --user flag

I don't understand what home folder of the user executing the podman command means. Are we talking about the user on the host who invoked podman create, podman start, etc.?

If so, wouldn't the HOME environment variable on the host be this user's home directory in the vast majority of cases? I don't understand how HOME is different from the home folder of the user executing the podman command.

Are you thinking of cases where someone might have (temporarily?) overridden HOME on the host to point to something other than their home directory for testing and such?

The issue with using the current user home directory is that the same
command would have different behaviors on different machines.

I don't understand this. HOME can also be different on different machines. How is HOME different from the current user home directory?

@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 25, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 25, 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. release-note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants