Skip to content

implement preserving env from host into vm in shell command #3830

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

Merged

Conversation

olamilekan000
Copy link
Contributor

change implements propagating env from host machine into the guest VM.

implements issue

@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch 2 times, most recently from 810b261 to d9e9da9 Compare August 13, 2025 18:59
@jandubois jandubois linked an issue Aug 13, 2025 that may be closed by this pull request
Copy link
Member

@jandubois jandubois left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM and seems to work.

I do have some feedback though...

(I also ran out of time and did not review the tests)

"XAUTHORITY",
"XDG_*",
"_*", // Variables starting with underscore are typically internal
}
Copy link
Member

@jandubois jandubois Aug 14, 2025

Choose a reason for hiding this comment

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

I would sort the builtin list alphabetically, so it is easier to see which variables are filtered.

And I think we should add more variables, but it is of course subject to discussion. Some suggestions:

LD_*
DYLD_*
SHLVL
UID
EUID
GROUP
GID
HOSTNAME

Edit: I had LINES and COLUMNS in the list originally, but changed my mind and removed them.

Not sure about excluding shell-specific variables:

BASH*
ZSH*
FPATH
ZDOTDIR

@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch 3 times, most recently from 98e8fb3 to 523b2bf Compare August 14, 2025 08:21
@alexandear alexandear requested a review from Copilot August 14, 2025 09:05
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR implements environment variable propagation from the host machine to the guest VM in shell commands, addressing the ability to preserve selected environment variables when executing commands within Lima VMs.

  • Adds environment filtering utilities with configurable blocklist/allowlist support
  • Introduces --preserve-env flag to shell commands for controlled environment propagation
  • Updates nerdctl.lima wrapper script to use the new preserve-env functionality

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
pkg/envutil/envutil.go New utility package for filtering environment variables with builtin blocklist and pattern matching
pkg/envutil/envutil_test.go Comprehensive test coverage for environment filtering functionality
pkg/limainfo/limainfo.go Adds shell environment blocklist to Lima info structure
cmd/limactl/shell.go Implements --preserve-env flag and environment variable injection in shell commands
cmd/nerdctl.lima Updates wrapper script to use --preserve-env flag

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Copy link
Member

@alexandear alexandear left a comment

Choose a reason for hiding this comment

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

Left a few suggestions.

@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch from 523b2bf to 53e21f5 Compare August 14, 2025 14:16
@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch from 53e21f5 to dd731fa Compare August 14, 2025 14:19
Copy link
Member

@jandubois jandubois left a comment

Choose a reason for hiding this comment

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

More feedback.

Meetings coming up, so again didn't review tests yet.

@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch from dd731fa to 35c0bb5 Compare August 14, 2025 17:18
Copy link
Member

@jandubois jandubois left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM

I only have a few nit-picks, that I don't care if you want to address them or not, but I do think the tests should cover that the allow list takes precedence over the block list.

@jandubois
Copy link
Member

@lima-vm/maintainers I think this PR is almost ready to be merged.

Please add some feedback about the default block list! Do you agree with all the entries, or should some not be blocked (like the shell-specific ones)? Or are there setting that are missing?

We can still update the list after the PR is merged, but I think once 2.0.0 is released, any further changes would be breaking backwards compatibility.

@olamilekan000 olamilekan000 force-pushed the implement-preserving-env-to-shell branch from 35c0bb5 to 71e227b Compare August 14, 2025 21:10
jandubois
jandubois previously approved these changes Aug 14, 2025
Copy link
Member

@jandubois jandubois left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM

One thing I stumbled over when reviewing the latest test update was that I expected allowList to come before blockList in the arguments:

filterEnvironmentWithLists(env, blockList, allowList []string)

Both because the allow list takes precedence, and because it comes alphabetically first.

But maybe that is just a personal preference. Feel free to either change or ignore, I'm also fine with merging as-is.

I will leave the PR open for another day or so to give other maintainers a chance to comment on the DefaultBlockList.

Copy link
Member

@jandubois jandubois left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM

Comment on lines +132 to +135
// GetDefaultBlockList returns a copy of the default block list.
func GetDefaultBlockList() []string {
return slices.Clone(defaultBlockList)
}
Copy link
Member

Choose a reason for hiding this comment

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

Could we move this function to the top, right after the var defaultBlockList?

Usually, unexported functions go below exported ones.

Copy link
Member

Choose a reason for hiding this comment

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

I agree that it makes sense to have this function close to the definition because it is a small exported function directly tied to the variable.

In general we don't follow a rules that unexported functions go to the bottom. Most of the code seems to follow the pattern of defining helper functions before the exported function that uses them.

@jandubois jandubois merged commit c241c8a into lima-vm:master Aug 16, 2025
61 of 63 checks passed
@jandubois jandubois added this to the v2.0.0 milestone Aug 16, 2025
@AkihiroSuda AkihiroSuda added the enhancement New feature or request label Aug 18, 2025
@AkihiroSuda AkihiroSuda added impact/changelog area/cli limactl CLI user experience labels Aug 18, 2025
"ZDOTDIR",
"ZSH*",
"_*", // Variables starting with underscore are typically internal
}
Copy link
Member

Choose a reason for hiding this comment

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

Was this list taken from somewhere else?
Where is the upstream of this list?

Copy link
Member

Choose a reason for hiding this comment

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

There is no upstream afaik, we just made it up. Which is why I asked for feedback on it. Did check it against my own setup on macOS, and the blocks make sense to me. I'm unsure if we are blocking too much with the BASH* and ZSH* blocks.

@@ -1,3 +1,3 @@
#!/bin/sh
set -eu
exec lima nerdctl "$@"
exec limactl shell --preserve-env default nerdctl "$@"
Copy link
Member

Choose a reason for hiding this comment

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

Needs a comment to explain the reason

Copy link
Member

Choose a reason for hiding this comment

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

What about docker.lima, etc. ?

Copy link
Member

Choose a reason for hiding this comment

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

It was an oversight. I only mentioned nerdctl.lima because it always runs in the VM, but didn't think about docker.lima because I always have a local client.

So yes, docker.lima needs it too. I don't know about the others, but maybe we should add it to all of them.

In some ways you could argue that --preserve-env should be the default unless the instance is --plain, but I don't think we want to make this change because it is not backwards compatible (and having it work differently based on instance type is confusing).

Copy link
Member

Choose a reason for hiding this comment

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

--preserve-env should be the default

Scary to leak the credentials by default

@@ -54,6 +55,7 @@ func newShellCommand() *cobra.Command {
shellCmd.Flags().String("shell", "", "Shell interpreter, e.g. /bin/bash")
shellCmd.Flags().String("workdir", "", "Working directory")
shellCmd.Flags().Bool("reconnect", false, "Reconnect to the SSH session")
shellCmd.Flags().Bool("preserve-env", false, "Propagate environment variables to the shell")
Copy link
Member

Choose a reason for hiding this comment

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

Needs an integration test and the document to clarify the block list

}

func getBlockList() []string {
blockEnv := os.Getenv("LIMA_SHELLENV_BLOCK")
Copy link
Member

Choose a reason for hiding this comment

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

@AkihiroSuda
Copy link
Member

Late to the party, but please check the comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli limactl CLI user experience enhancement New feature or request impact/changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a --with-env flag to limactl shell
4 participants