Skip to content

fix: run every docker command through sudo when use_sudo is set - #485

Merged
tas50 merged 1 commit into
mainfrom
fix/use-sudo-docker-commands
Aug 23, 2026
Merged

fix: run every docker command through sudo when use_sudo is set#485
tas50 merged 1 commit into
mainfrom
fix/use-sudo-docker-commands

Conversation

@tas50

@tas50 tas50 commented Aug 23, 2026

Copy link
Copy Markdown
Member

Reported behaviour: use_sudo: true does not help on a host where the Docker daemon socket needs root -- the very case the README points at it for.

The bug

use_sudo reached exactly one command: the bare docker probe in verify_dependencies.

Kitchen's ShellOut#run_command treats sudo as a per-call option -- it reads :use_sudo out of the options hash it is handed and knows nothing about config. docker_command builds its own command line and never passed it along, so every build, run, port, inspect, exec, cp, and rm still ran as the invoking user.

The result is the worst shape of failure: the probe succeeds under sudo, so the driver reports Docker is usable, and kitchen create then dies on the first command that actually touches the daemon.

The transport is affected the same way and separately: it is its own plugin with its own config, and it runs docker exec and docker cp. Fixing only the driver would have moved the failure from create to converge.

The fix

  • docker_command adds the sudo options when use_sudo is set.
  • sudo_command is honoured, for hosts that use something other than sudo -E (doas, a wrapper script).
  • The transport gains both options, and the README says to set them in both places.

Confirmation

Reproduced against Docker 29.7.2 (Docker Desktop 4.87.0, macOS/arm64) with Test Kitchen 4.1.1, using a docker wrapper on PATH that refuses unless it was launched through sudo -- so a run can only succeed if every command went through it:

driver:
  name: docker
  binary: dockerwrap
  use_sudo: true
transport:
  name: docker
  binary: dockerwrap
  use_sudo: true

Before:

       permission denied while trying to connect to the Docker daemon socket
>>>>>> Message: 1 actions failed.

After -- full kitchen converge against a real ubuntu-24.04 container:

       HELLO FROM PROVISIONER
       Finished converging <default-ubuntu-2404> (0m0.63s).

with 14 recorded sudo invocations (the probe plus 13 real docker commands) where there had been 1.

rake style clean; rspec 313 examples, 0 failures (6 new).

`use_sudo` reached exactly one command: the bare `docker` probe in
`verify_dependencies`. Kitchen's `run_command` takes sudo as a call option
rather than reading configuration, and `docker_command` never passed it, so
every build, run, port, inspect, exec, cp, and rm still ran as the invoking
user.

That made the option useless for the case it exists for. On a host where the
daemon socket needs root, `use_sudo: true` -- the answer the README gives for
"permission denied while trying to connect to the Docker daemon socket" --
changed nothing: the probe succeeded under sudo and `kitchen create` then
failed on the first real command.

`docker_command` now adds the sudo options when `use_sudo` is set, and honours
a `sudo_command` for hosts that use something other than `sudo -E`.

The transport gains `use_sudo` and `sudo_command` too. It runs its own
`docker exec` and `docker cp`, so setting them only on the driver would move
the failure from create to converge rather than fixing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@tas50
tas50 force-pushed the fix/use-sudo-docker-commands branch from 51617e3 to 8769189 Compare August 23, 2026 16:52
@tas50
tas50 merged commit 2481aad into main Aug 23, 2026
107 checks passed
@tas50
tas50 deleted the fix/use-sudo-docker-commands branch August 23, 2026 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant