feat(docker): linux privilege elevation for Docker and Podman providers#737
feat(docker): linux privilege elevation for Docker and Podman providers#737skevetter wants to merge 3 commits into
Conversation
…providers Rootful Docker/Podman daemons expose a socket accessible only to root and the docker group, so the local provider fails with a permission error for users outside that group. Adding an explicit, opt-in privilege-elevation mechanism lets those users run the provider without joining the group or running the whole process as root. Add a DOCKER_ELEVATION / PODMAN_ELEVATION option (none, pkexec, sudo, doas) that wraps every docker/podman invocation with the chosen helper. To avoid a prompt per command and to keep the interactive prompt out of the short per-command probe timeouts, authentication is performed once up front at driver construction, warming the OS credential cache for the rest of the operation. Client-only runtime detection stays unelevated.
✅ Deploy Preview for images-devsy-sh canceled.
|
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds optional ChangesDocker privilege elevation
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ProviderConfig
participant NewDockerDriver
participant DockerHelper
participant Elevator
participant DockerCLI
ProviderConfig->>NewDockerDriver: provide elevation setting
NewDockerDriver->>Elevator: create configured helper
NewDockerDriver->>DockerHelper: EnsureElevated()
DockerHelper->>Elevator: authenticate once
Elevator->>DockerCLI: run helper --version
DockerHelper->>Elevator: wrap Docker command
DockerHelper->>DockerCLI: execute elevated command
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for devsydev canceled.
|
Extract pkexec/sudo/doas string constants (goconst), wrap long lines (golines), and mark the trusted-config exec calls //nolint:gosec (G204).
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pkg/docker/helper.go`:
- Around line 529-537: The buildCmd flow must preserve DockerHelper.Environment
across Elevator.wrap instead of allowing sudo/doas to discard provider
configuration such as DOCKER_HOST. Update the elevation handling around
EnsureElevated and Elevator.wrap to explicitly forward or allowlist the required
Docker configuration variables, or reject incompatible
elevation-plus-environment configurations before executing the command.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d4dca378-0bc6-46a6-9317-7906d1697aba
📒 Files selected for processing (8)
pkg/docker/elevate.gopkg/docker/elevate_test.gopkg/docker/helper.gopkg/driver/docker/docker.gopkg/options/resolve.gopkg/provider/provider.goproviders/docker/provider.yamlproviders/podman/provider.yaml
skevetter
changed the title
sudo/pkexec/doas reset the child environment, so provider-configured variables such as DOCKER_HOST (set via the docker/podman env block) were silently dropped when elevation was active. Forward them explicitly through env(1) so the elevated docker command receives the intended configuration.
1 participant
Closes #732
Summary
Rootful Docker/Podman daemons expose a socket accessible only to root and the
dockergroup, so the local provider fails with a permission error for users outside that group. Joining the group grants persistent root-equivalent access, and running the whole process as root is undesirable.This adds an explicit, opt-in privilege-elevation mechanism:
DOCKER_ELEVATION(docker provider) andPODMAN_ELEVATION(podman provider): one ofnone(default),pkexec,sudo,doas.DockerHelper.buildCmdchoke point.--version) stays unelevated.This resolves both problems reported in #732 when using a
pkexecwrapper: multiple simultaneous auth dialogs, and the operation failing before password entry completed.Notes
none— elevating would target a separate rootful instance.pkexectargets local desktop sessions with a running polkit agent; usesudo/doason headless/SSH hosts.Summary by CodeRabbit
pkexec,sudo, anddoas, with interactive authentication.noneto run commands normally.