[Bug]: docker shim executes `docker login` as /usr/bin/login ("Cannot possibly work without effective root")

[sverdlov93]

Summary

The Boost docker shim in /tmp/boost/tools mis-executes docker login … as the shadow-utils /usr/bin/login binary, breaking all container logins on hosts where /tmp/boost/tools is on PATH ahead of /usr/bin. This took down Docker setup in CI (GitHub Actions self-hosted runners) for jfrog/fly-service and jfrog/fly-desktop.

Observed error:

login: Cannot possibly work without effective root

Environment

• Boost binary: /tmp/boost/tools/boost-arm64, statically-linked ELF aarch64, BuildID 397bf566827c6454219a2eba05fcdec8c27c2b2c, rebuilt 2026-06-18 11:26
• Host: self-hosted GitHub Actions runners (Fly-Runner-US-ARM), Ubuntu, ARM64
• Real docker: /usr/bin/docker (Docker 29.1.5) — works fine
• Boost shims present in /tmp/boost/tools (all symlinks → boost-arm64): docker (created May 17), sh, bash, dash (created/rebuilt Jun 18 11:26)

Reproduction (minimal)

Same command, same env, same host — only the docker binary differs:

echo "$TOKEN" | /tmp/boost/tools/docker login flyjfrog.jfrog.io --username="$USER" --password-stdin
# -> login: Cannot possibly work without effective root      (exit 1)

echo "$TOKEN" | /usr/bin/docker        login flyjfrog.jfrog.io --username="$USER" --password-stdin
# -> Login Succeeded                                          (exit 0)

Root cause

/tmp/boost/tools is prepended to PATH ahead of /usr/bin:

PATH=/home/ubuntu/actions-runner/_work/_tool/fly/1.4.15/arm64:/tmp/boost/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:...

So docker resolves to the Boost shim. When a tool runs sh -c "echo $PASS | docker login <registry> --username=\"<user>\" --password-stdin", Boost's docker shim drops the login subcommand and execs the second token (login) as a standalone program — which resolves to /usr/bin/login (shadow-utils), printing Cannot possibly work without effective root (euid != 0).

Process chain proven via /proc/<pid>/exe (all the intermediate sh/docker/bash resolve to boost-arm64):

fly setup
└─ sh -c "echo $CONTAINER_MANAGER_PASS | docker login … --password-stdin"   exe=/tmp/boost/tools/boost-arm64
   └─ docker login … --password-stdin                                       exe=/tmp/boost/tools/boost-arm64
      └─ login <registry> --username=… --password-stdin                     -> /usr/bin/login  ✗

The docker symlink alone existed since May 17 without breaking anything; the regression began with the Jun 18 11:26 boost-arm64 rebuild (and the new sh/bash/dash shims), which aligns exactly with the CI onset date.

Impact

• All docker login / helm registry login style flows that go through a Boost-shimmed docker fail on affected hosts.
• Surfaced as docker ✗ / failed to login to container registry in jfrog/fly-service and jfrog/fly-desktop CI on self-hosted ARM runners since 2026-06-18. GitHub-hosted runners are unaffected (no /tmp/boost).

Evidence (CI runs)

• A vs B docker login (boost shim fails, real docker succeeds): https://github.com/jfrog/fly-service/actions/runs/27951119660
• /proc/<pid>/exe ancestry capture showing docker→login via boost-arm64: https://github.com/jfrog/fly-service/actions/runs/27951007101

Expected behavior

The Boost docker shim must forward the full argument vector to the real docker binary unchanged (docker login <args> → real docker login <args>), never collapse login into a standalone command.

Suggested fixes

1. Fix the Boost shim argument parsing so subcommands (login, build, etc.) are preserved when delegating to the real binary.
2. Avoid shadowing security-sensitive binaries (login, newgrp, sg) and core tools in a PATH dir that can leak into unrelated process trees (e.g. CI runner services).
3. Ensure Boost's shim dir does not contaminate the GitHub Actions runner-service PATH.

[sverdlov93]

Confirmed via controlled A/B on the live runners

Same self-hosted runner pool (Fly-Runner-US-ARM), same single cold jfrog/fly-action@v1 docker setup per job. The only variable changed is the boost docker shim:

Intervention	fly-action outcome
Move /tmp/boost/tools/docker aside	✅ success
Control (boost shim present)	❌ failure
Control (boost shim present)	❌ failure
DISABLE_BOOST=1 exported via $GITHUB_ENV	❌ failure

Removing the boost docker shim is the only change that flips fail → success → conclusive proof the shim is the cause.

Evidence run: https://github.com/jfrog/fly-service/actions/runs/27955150163

Mitigations that do NOT work

• DISABLE_BOOST=1 via $GITHUB_ENV does not help. The runner already launches actions through boost_node, and the /tmp/boost/tools PATH shims remain in effect, so the env toggle never reaches the action's node launch.
• Stripping /tmp/boost/tools from PATH in a prior run: step does not help either — boost_node re-injects /tmp/boost/tools into the PATH of the spawned fly child after the strip (a run: step shows docker -> /usr/bin/docker, but the action's child still resolves the boost shim).

Only effective remediation

Physically remove the boost shims from the runner / runner-service environment (e.g. remove /tmp/boost/tools from PATH or delete the shim dir and restart the runner). An env flag is not sufficient given the boost_node wrapping.