Calling kubectl rootless with "OverrideFlags" changes datadir to current directory

[dreia2k]

Hello,

when calling kubectl as non root user with an OverrideFlag, as defined in func MustFindString, dataDir gets changed to the current working directory.

This is called from the cmd/k3s/main.go main function which calls func findDataDir

// in cmd/k3s/main.go main()
dataDir := findDataDir(os.Args)

// in cmd/k3s/main.go findDataDir()
dataDir = configfilearg.MustFindString(args, "data-dir") // this finds the OverrideFlag and returns it

So every time --version or --help is passed as an option, a directory with the name of the flag gets created in e.g.: ./--version.
Is this an intended behaviour?
It seems weird to me and causes these folders littering my current directory.

[brandond]

Can you provide the exact command you're running that triggers this?

[brandond]

Yes. That is the desired behavior. If K3s is run by root, and extracts content to the data-dir, then k3s doesn't create the user data-dir when run as a non-root user. It just uses the bits from the system-level install. If you run it as a non-root user, and the system level install isn't present, then it extracts the stuff to your home dir and then runs it from there.

I sure can't reproduce the other things you're reporting though. I think you're going to have figure that out on your own.

[dreia2k]

Okay, thank you for your help so far.

I get that, but is it desired to use the current working directory instead of ~/.rancher/k3s?
Because without one of those OverrideFlags it uses the ~/.rancher/k3s dir just fine.

I added some debug output to always show dataDir when calling kubectl.

dreia2k@server:~/git/k3s_1.30/dist/artifacts$ ./k3s kubectl version
INFO[0000] dataDir: /home/dreia2k/.rancher/k3s
...

dreia2k@server:~/git/k3s_1.30/dist/artifacts$ ./k3s kubectl --version
INFO[0000] dataDir: /home/dreia2k/git/k3s_1.30/dist/artifacts/--version
...

[brandond]

No. That's the bit that I can't seem to reproduce. If you can figure out why that is only happening for you, you're probably on track to a fix.

[brandond]

Oh hmm, it appears that this is specific to particular flags. I suspect this is due to special handling of the --version and --help flag by urfave/cli. Other kubectl flags like --client don't trigger this same behavior.

• k3s kubectl --version: bad
• k3s kubectl --help: bad
• k3s kubectl --client: ok
• k3s kubectl --warnings-as-errors: ok

[brandond]

I'll open an issue to track this. thanks for walking me through it!