Skip to content

Comments

client: minor cleanup, linting- and bug-fixes#47881

Merged
thaJeztah merged 3 commits intomoby:masterfrom
thaJeztah:client_cleanups
Jun 3, 2024
Merged

client: minor cleanup, linting- and bug-fixes#47881
thaJeztah merged 3 commits intomoby:masterfrom
thaJeztah:client_cleanups

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented May 31, 2024

client: Client.NetworkInspectWithRaw: minor cleanup

Make this code slightly more idiomatic, and make it clear in what cases
we don't return an actual response, but an empty / default struct.

client: ensureReaderClosed: make linters happier

client: Client.doRequest: fix closing filehandle and reversed errors

commit 1a5dafb (#39588) improved the error messages
produced by adding a check if the client is using as an elevated user. For
this, it attempts to open \\.\PHYSICALDRIVE0.

However, it looks like closing the file landed in the wrong branch of the
condition, so the file-handle would not be closed when the os.Open succeeded.

Looking further into this check, it appears the conditions were reversed;
if the check fails, it means the user is not running with elevated
permissions, but the check would use elevatedErr == nil.

Fix both by changing the condition to elevatedErr != nil.

While at it, also changing the string to use a string-literal, to reduce
the amount of escaping needed.

- Description for the changelog

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

@thaJeztah thaJeztah added this to the 27.0.0 milestone May 31, 2024
@thaJeztah thaJeztah self-assigned this May 31, 2024
Comment on lines 187 to 191
if f, elevatedErr := os.Open(`\\.\PHYSICALDRIVE0`); elevatedErr == nil {
_ = f.Close()
err = errors.Wrap(err, "in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect")
} else {
f.Close()
err = errors.Wrap(err, "this error may indicate that the docker daemon is not running")
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm actually wondering if the condition as a whole is flipped, but I don't have a Windows machine to try;

From reading the code, I THINK an error would be returned if the use is NOT privileged; in that case, opening \\.\PHYSICALDRIVE0 would fail, and the "try running with elevated privileges" would be the error to show.

If that does not fail, and the most likely reason for the original error was that the daemon was not running.

All that said, I wonder if this whole code should be handled elsewhere; after all, we should know how the client is trying to connect, so I assume we can check there if the user has privileges to open the named pipe?

Copy link
Member

Choose a reason for hiding this comment

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

Looking at the 'How to verify' section in #39588 (comment), I'm pretty sure you're right. The code doesn't match the intended behavior.

Once you replace elevatedErr == nil with elevatedErr != nil, f.Close() is located in the right branch. Maybe worth fixing that instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup! Thanks for confirming my suspicion; I updated the PR with that change; PTAL

@thaJeztah thaJeztah marked this pull request as draft May 31, 2024 21:11
@thaJeztah

This comment was marked as resolved.

@thaJeztah thaJeztah marked this pull request as ready for review May 31, 2024 21:14
thaJeztah added 3 commits June 3, 2024 10:52
Make this code slightly more idiomatic, and make it clear in what cases
we don't return an actual response, but an empty / default struct.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
commit 1a5dafb improved the error messages
produced by adding a check if the client is using as an elevated user. For
this, it attempts to open `\\.\PHYSICALDRIVE0`.

However, it looks like closing the file landed in the wrong branch of the
condition, so the file-handle would not be closed when the os.Open succeeded.

Looking further into this check, it appears the conditions were reversed;
if the check _fails_, it means the user is not running with elevated
permissions, but the check would use elevatedErr == nil.

Fix both by changing the condition to `elevatedErr != nil`.

While at it, also changing the string to use a string-literal, to reduce
the amount of escaping needed.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah
Copy link
Member Author

Interesting failure in setup-buildx-action; https://github.com/moby/moby/actions/runs/9347176230/job/25723674583?pr=47881

Buildx version
  /usr/bin/docker buildx version
  github.com/docker/buildx v0.14.1 59582a88fca7858dbe1886fd1556b2a0d79e43a3
Creating a new builder instance
  /usr/bin/docker buildx create --name builder-17718e89-603b-4cb3-bd5c-490a171818f1 --driver docker-container --buildkitd-flags --allow-insecure-entitlement security.insecure --allow-insecure-entitlement network.host --use
  builder-17718e89-603b-4cb3-bd5c-490a171818f1
Booting builder
  /usr/bin/docker buildx inspect --bootstrap --builder builder-17718e89-603b-4cb3-bd5c-490a171818f1
  #1 [internal] booting buildkit
  #1 pulling image moby/buildkit:buildx-stable-1
  #1 pulling image moby/buildkit:buildx-stable-1 0.2s done
  #1 ERROR: Error response from daemon: unauthorized: authentication required
  ------
   > [internal] booting buildkit:
  ------
  ERROR: Error response from daemon: unauthorized: authentication required
Error: The process '/usr/bin/docker' failed with exit code 1

Copy link
Member

@akerouanton akerouanton left a comment

Choose a reason for hiding this comment

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

LGTM

@thaJeztah thaJeztah added kind/bugfix PR's that fix bugs kind/refactor PR's that refactor, or clean-up code labels Jun 3, 2024
@thaJeztah thaJeztah merged commit 1f35940 into moby:master Jun 3, 2024
@thaJeztah thaJeztah deleted the client_cleanups branch June 3, 2024 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/bugfix PR's that fix bugs kind/refactor PR's that refactor, or clean-up code status/2-code-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants