Fix auto-update re-exec arguments modified by aliases

[vapopov]

In this PR fixed issue related tsh {alias} if we define in alias same executable path of tsh, for instance:

~/.tsh/config/config.yaml

aliases:
  "loginvadym": ".build/tsh login --proxy=localhost:8443 --auth=local --user=vadym --insecure"

we don't spawn new process, instead just re-run the tsh main function with modified execution arguments

teleport/tool/tsh/common/aliases.go

Lines 205 to 221 in e50dae9

	// if execPath is our path, skip re-execution and run main directly instead.
	// this makes for better error messages in case of failures.
	if execPath == currentExecPath {
	log.Debugf("Self re-exec command: tsh %v.", arguments)
	return trace.Wrap(ar.runTshMain(ctx, arguments))
	}
	cmd := exec.Command(execPath, arguments...)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	log.Debugf("Running external command: %v", cmd)
	err = ar.runExternalCommand(cmd)
	if err == nil {
	return nil
	}

but in updater we use os.Args arguments, not modified ones by alias runner

teleport/lib/autoupdate/tools/updater.go

Lines 351 to 352 in e50dae9

	if err := syscall.Exec(path, append([]string{path}, os.Args[1:]...), env); err != nil {
	return 0, trace.Wrap(err)

this produce issue with updater, when it executed by alias

vpopov@Vadyms-MBP-2 teleport-docker % ./build/tsh loginvadym
Update progress: [▒▒▒▒▒▒▒▒▒▒] (Ctrl-C to cancel update)
ERROR: recursive alias "loginvadym"; correct alias definition and try again

discussion
Related: https://github.com/gravitational/cloud/issues/10053

changelog: Fixed client tools autoupdates executed by aliases (causes recursive alias error)

[Tener]

LGTM. After reading the issue analysis my first suggestion would be to move away from the global os.Args, so I'm happy to see this is indeed the fix.

Also, very cool feature 👍

Nit: perhaps worth mentioning this bugfix in the changelog? A bit of marketing for both features involved ;-)

[vapopov]

@hugoShaka could you please take a look when you have time

[hugoShaka]

Should we have a test covering the re-exec with alias mechanism? I'm worried someone might break it again in the future and won't detect it.

[sclevine]

@hugoShaka reminder to review when you have a chance 🙂

[vapopov]

@hugoShaka I had to restore this part since your last review 894aab9#diff-6ddd22bd400fc52c2062de3b1fc775fdaf05594f85c5ffa5a02262af40f5d62dL163-L182

I mislead myself with this check, after verifying rfd again and draft implementation we should keep priority of env variable version set over that we receive from webapi/find endpoint, in such case if I do login with

TELEPORT_TOOLS_VERSION=off tsh login --insecure --proxy localhost:8443 --user teleport

We able to completely disable updates, same as override the version which is defined in cluster. Let say cluster target version is set to 17.1.3 but we want to use 17.1.2 instead

$ TELEPORT_TOOLS_VERSION=17.1.2 tsh login --insecure --proxy localhost:8443 --user teleport
Update progress: [▒▒▒▒▒▒▒▒▒▒] (Ctrl-C to cancel update)
Enter password for Teleport user teleport:
WARNING: You are using insecure connection to Teleport proxy https://localhost:8443
Enter an OTP code from a device:
> Profile URL:        https://localhost:8443
  Logged in as:       teleport
  Cluster:            logrotate.teleport
  Roles:              editor
  Kubernetes:         enabled
  Valid until:        2025-01-17 09:47:45 -0800 PST [valid for 12h0m0s]
  Extensions:         login-ip, permit-agent-forwarding, permit-port-forwarding, permit-pty, private-key-policy

$ tsh --insecure version
Teleport v17.1.2 git:v17.1.2-0-g5274176 go1.23.4
Proxy version: 17.0.0-dev
Proxy: localhost:8443

So, the version is picked from the environment variable in this case. After logging out and re-logging in, the client tools should update to the version defined in the cluster configuration, exmaple:

$ tsh login --insecure --proxy localhost:8443 --user teleport
This is wrapper script
Update progress: [▒▒▒▒▒▒▒▒▒▒] (Ctrl-C to cancel update)
Enter password for Teleport user teleport:
WARNING: You are using insecure connection to Teleport proxy https://localhost:8443
Enter an OTP code from a device:
> Profile URL:        https://localhost:8443
  Logged in as:       teleport
  Cluster:            logrotate.teleport
  Roles:              editor
  Kubernetes:         enabled
  Valid until:        2025-01-17 09:51:37 -0800 PST [valid for 12h0m0s]
  Extensions:         login-ip, permit-agent-forwarding, permit-port-forwarding, permit-pty, private-key-policy

$ tsh --insecure version
Teleport v17.1.3 git:v17.1.3-0-g9726471 go1.23.4
Proxy version: 17.0.0-dev
Proxy: localhost:8443

---

Another part is related to double re-execution, as we have LocalCheck, which is responsible for checking the TELEPORT_TOOLS_VERSION environment variable, and RemoteCheck, which makes a remote call to the proxy webapi/find endpoint to determine the update version.

LocalCheck is integrated into tsh and tctl before any other initialization, including actual command parsing. If the version environment variable is set and either no version was previously installed or the specified version differs from the installed one, the update and re-execution are triggered, bypassing any further logic.

RemoteCheck executed only for login command or re-login action.

For instance we have /usr/local/bin/tsh initially installed from deb/rpm or tarball, version 1.0.0, previously it was already updated by client tools autoupdate and we have binary ~/.tsh/bin/tsh with version 2.0.0, in this setup we want to re-login to the same cluster where target version was updated to 3.0.0.

When we run a command usr/local/bin/tsh login --proxy example.proxy.com, updater logic verifies that env wasn't set, after that it checks the version by tools directory ~/.tsh/bin/tsh, if we have installed tool there, we re-execute it with same args and envs, ~/.tsh/bin/tsh login --proxy example.proxy.com (first re-execution). In login command we hit RemoteCheck where version is set to 3.0.0 which is different with current one 2.0.0, we run update and re-execution (second re-execution). ~/.tsh/bin/tsh replace itself in the same path with newer version.

Previously we set TELEPORT_TOOLS_VERSION=off to first re-execution, which leads to ignoring RemoteCheck thats why it misleads me with this change 894aab9#diff-6ddd22bd400fc52c2062de3b1fc775fdaf05594f85c5ffa5a02262af40f5d62dL163-L182 , instead I've added check of execution path to allow second re-execution: https://github.com/gravitational/teleport/pull/50228/files#diff-6ddd22bd400fc52c2062de3b1fc775fdaf05594f85c5ffa5a02262af40f5d62dR341-R348

[public-teleport-github-review-bot]

@vapopov See the table below for backport results.

Branch	Result
branch/v15	Failed
branch/v16	Failed
branch/v17	Create PR