1.34 - "minikube delete --purge" deletes entire MINIKUBE_HOME directory if env var does not end with "/.minikube"

[kaawilcox]

What Happened?

For legacy reasons, my environment had MINIKUBE_HOME explicitly specified. Prior to 1.34.0, if the MINIKUBE_HOME path did not end with /.minikube, all commands would functionally append /.minikube to the path before execution. If no .minikube directory existed in the directory specified by MINIKUBE_HOME, the command minikube delete --purge would have no effect.

Now, as of 1.34.0, if MINIKUBE_HOME is defined and does not end with /.minikube, the command minikube delete --purge deletes the full directory specified by MINIKUBE_HOME if no .minikube directory exists within the directory. This can be extremely destructive if MINIKUBE_HOME is specified to a location such as the user's home folder.

I verified that rolling back to 1.33.1 prevents the problem, and I reproduced the issue on Windows 10 and 11. I have not had a chance to test it on a Linux distribution.

Configuration documentation for MINIKUBE_HOME at the time of writing:

MINIKUBE_HOME - (string) sets the path for the .minikube directory that minikube uses for state/configuration. If you specify it to /path/to/somewhere and somewhere is not equal to .minikube, the final MINIKUBE_HOME will be /path/to/somewhere/.minikube. Defaults to ~/.minikube if unspecified. Please note: this is used only by minikube and does not affect anything related to Kubernetes tools such as kubectl.

Documentation for delete --purge flag at the time of writing:

Set this flag to delete the '.minikube' folder from your user directory.

To reproduce:

1. Install minikube 1.34.0.
2. Open up a new terminal.
   • Occurs in PowerShell and GitBash
   • Elevated permissions are not necessary, so a non-admin terminal will suffice
3. Set the MINIKUBE_HOME environment variable to a location to which the logged-in user has access.
4. Run minikube delete --purge. Note: You do not need to start minikube at all for this issue to occur.

The log files below were generated with MINIKUBE_HOME set to %HOME%\Desktop\test-minikube.

Attach the log file

1.34.0-with-.minikube-folder.txt
1.34.0-without-.minikube-folder.txt

Operating System

Windows

Driver

N/A

[johnmatthiggins]

I think I may have found a fix for this issue. I'd like to work on this.

[johnmatthiggins]

This bug seems to come from this function.

func MiniPath() string {
	minikubeHomeEnv := os.Getenv(MinikubeHome)
	if minikubeHomeEnv == "" {
		return filepath.Join(homedir.HomeDir(), ".minikube")
	}
	if filepath.Base(minikubeHomeEnv) == ".minikube" {
		return minikubeHomeEnv
	}

	legacyMinikubeHome := filepath.Join(minikubeHomeEnv, ".minikube")
	if _, err := os.Stat(legacyMinikubeHome); !os.IsNotExist(err) {
		return legacyMinikubeHome
	}
	return filepath.Clean(minikubeHomeEnv)
}

The problem is that whether the legacy home directory functionality is used depends on the existence of a directory at $MINIKUBE_HOME/.minikube. If the directory doesn’t exist the $MINIKUBE_HOME is assumed to be the actual home and the ‘.minikube’ directory name is not appended to it. This is what resulted in an unexpected directory deletion.

The pull request that introduced this behavior was intending to make backwards compatibility more convenient but it seems to have caused a bigger problem. The pull request was resolving an issue about the confusing behavior of MiniPath. However, this seems to have created a bigger issue.

I think it would be best to move back to the old version of the code and add some tests that demonstrate the backwards compatible behavior better.

[johnmatthiggins]

I made a pr with some changes that fix this bug.
/assign

[medyagh]

I think we kind of did a mistake in the previous release not to think about this, the rightthing to do is,
in the delete --purge code. we need to Check What folders we are deleting...and if there is any folder other than minikube sub folders we should Warn the user if they wanna proceed.

alternatvely we should enforce users to set their minikube home folder to something that is called .minikube, so in the purge we only delete .minikube folder

I wish there was a way to Tag or label files and folders created by minikube (like when u create a docker resource)

that way we could be 100% sure we deleting only minikube

[johnmatthiggins]

I think we kind of did a mistake in the previous release not to think about this, the rightthing to do is, in the delete --purge code. we need to Check What folders we are deleting...and if there is any folder other than minikube sub folders we should Warn the user if they wanna proceed.

alternatvely we should enforce users to set their minikube home folder to something that is called .minikube, so in the purge we only delete .minikube folder

It seems like there are two options.

1. Make the program ask the user whether they want to delete their minikube home if it is a non-standard one, or
2. Make the program expect that there is a ".minikube" folder as a child of the specified MINIKUBE_HOME path if the MINIKUBE_HOME path doesn't end with ".minikube."

From what I understand, the goal going forward is to require the base name of the config directory to be ".minikube". Option 1 allows users to use a non-standard directory name for their minikube config. However, option 2 still requires a ".minikube" directory to exist somewhere on someone's system in order for their minikube instance to work.

I think option 2 is more in line with the overall goal of getting everyone switched over having their minikube config directory be named ".minikube". If you go with option 1 it allows people to use a directory named "mini-kube" for their config which would get you further away from the end goal.

[medyagh]

I still dont know the right solution but I know for sure we have to add these guard rails regarless of the solution

1- if $HOME dir is the same as "minikube home folder" we should NOT delete it and tell the user they gotta do it manually and be cautious
2- if we notice non minikube sub-directories bellow

$ ls ~/.minikube
addons			certs			machines
ca.crt			config			profiles
ca.key			files			proxy-client-ca.crt
ca.pem			key.pem			proxy-client-ca.key
cache			logs
cert.pem		machine_client.lock

3- would be create a Flag File inside minikube with some signature that shows this folder was created by minikube
the flag could simply ".CREATED_BY_MINIKUBE" and would have the content of the version of minikube that created it...
so all of the folders and subfolders that miinikube creates would have that file.
so in the future (3-4 releases from now ) we could stop delete any folder that does not have the Flag file

however we wont be able to do that in next 1-2 versions because the next version of minikube wont be able to delete the .minikube folder that doesnt have the flag (created by previous versions)

so we should have a main function called "IsItMinikubeCreatedFolder" and we can use option 2 and 3 to verify
and then we can perfrom the delete otherwise we tell them to do manually..

4- We can also check the folders/files listed in 2 and the first time that we create/start the minikube home folder we should Warn them that they have chosen a Non Empty Directory for their home folder.

[medyagh]

@afbjorklund @prezha wdyt

[nirs]

I think the way to go is to accept MINIKUBE_HOME as the directory where the .minikube directory is created. There is no reason to let the user chose the ".minikube" part, and deleting MINIKUBE_HOME is wrong as deleting HOME.

There is no need to check the contents of the .minikube directory, it belongs to minikube and users should not keep their files there.

If a user configures MINIKUBE_HOME=/path/to/.minikube, minikube should use the directory /path/to/.minikube/.minikube.

[prezha]

it would be hard to tract which folders and files we (ie, minikube) created and which ones user added/modified in minikube home dir (eg, solutions relying on any filesystem features would be "impossible" to implement for all possible filesystems users might have, also, maintaining some kind of list of files/folders minikube created could be error-prone and unreliable, etc.)

on the other hand, there are cases where we do want minikube home dir completely removed (eg, sometimes that's used to check if it fixes an issue user is facing, in CI to "start from scratch", etc.)

up until v1.34.0 .minikube was the directory where all minikube-related stuff is stored (both from minikube and some from a user - like custom defaults, etc.) and with --purge, a user explicitly requests all of that to be removed

hence, "merging" the minikube-related stuff with other stuff is generally not a good idea

therefore, we could revert the change so that MiniPath() again always returns .minikube as the last element of the minikube home path, ensuring that we're operating within a dedicated folder (traditionally, it was .minikube and we have no reasons to change that)

however, if the only potential issue is while purging, whereas MiniPath() does not return .minikube as the last element of the path (eg, because MINIKUBE_HOME path does not end with .minikube and MINIKUBE_HOME dir does not contain .minikube subdir), we could, in that case, alternatively either:

• request a user to confirm purge request
• add --force flag to the minikube delete command to assume purge request confirmation (eg, also for use in a CI)