[24.0 backport] windows: fix --register-service when executed from within binary directory

[thaJeztah]

• backport of windows: fix --register-service when executed from within binary directory #46091
• (hopefully) fixes / addresses Unable to register dockerd.exe service on Windows 11 docker/for-win#13600

Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary code to be executed at build time when using cgo on Windows.

This issue was not limited to the go command itself, and could also affect binaries that use os.Command, os.LookPath, etc.

From the related blogpost (https://blog.golang.org/path-security):

Are your own programs affected?

If you use exec.LookPath or exec.Command in your own programs, you only need to
be concerned if you (or your users) run your program in a directory with untrusted
contents. If so, then a subprocess could be started using an executable from dot
instead of from a system directory. (Again, using an executable from dot happens
always on Windows and only with uncommon PATH settings on Unix.)

If you are concerned, then we’ve published the more restricted variant of os/exec
as golang.org/x/sys/execabs. You can use it in your program by simply replacing

At time of the go1.15 release, the Go team considered changing the behavior of os.LookPath() and exec.LookPath() to be a breaking change, and made the behavior "opt-in" by providing the golang.org/x/sys/execabs package as a replacement.

However, for the go1.19 release, this changed, and the default behavior of os.LookPath() and exec.LookPath() was changed. From the release notes: https://go.dev/doc/go1.19#os-exec-path

Command and LookPath no longer allow results from a PATH search to be found
relative to the current directory. This removes a common source of security
problems but may also break existing programs that depend on using, say,
exec.Command("prog") to run a binary named prog (or, on Windows, prog.exe)
in the current directory. See the os/exec package documentation for information
about how best to update such programs.

On Windows, Command and LookPath now respect the NoDefaultCurrentDirectoryInExePath
environment variable, making it possible to disable the default implicit search
of “.” in PATH lookups on Windows systems.

A result of this change was that registering the daemon as a Windows service no longer worked when done from within the directory of the binary itself:

C:\> cd "Program Files\Docker\Docker\resources"
C:\Program Files\Docker\Docker\resources> dockerd --register-service
exec: "dockerd": cannot run executable found relative to current directory

Note that using an absolute path would work around the issue:

C:\Program Files\Docker\Docker>resources\dockerd.exe --register-service

This patch changes registerService() to use os.Executable(), instead of depending on os.Args[0] and exec.LookPath() for resolving the absolute path of the binary.

(cherry picked from commit 3e8fda0)

- What I did

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)