Skip to content

Conversation

lnlrbr
Copy link

@lnlrbr lnlrbr commented Dec 24, 2024

Resolve problem described in [JENKINS-74995].
Summary: It's not possible to use rootless mode with the actual implementation as the plugin retrieves the user (agent) UID:GID via the 'id' command and the returned value is not the one expected in a rootless environment (i.e. "0:0"), so builds fail.
The provided change adds a test to look if we are in a rootless environment and returns the relevant value if needed.

Testing done

Tests were done with builds executed on two Linux nodes, one configured with Docker rootless mode and the other with Podman.
The pipelines include a 'docker' and a 'dockerfile' agent section.
There is some write access in the "build" stage to the mounted workspace.
If builds are done with the not modified plugin, the run part is done under the current (jenkins) user '-u 1001:1001', and builds can failed for not enough permissions on mounted volumes, or can lead to files owned to root inside the workspaces.
With builds done with the modified plugin, if a rootless environment is detected, the docker run part is done with the user parameter set to '-u 0:0'.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@imoazeem
Copy link

+1

@imoazeem
Copy link

Does anyone have an update on whether this pull request will be reviewed and merged to add support for a rootless Docker setup ?

@concatime
Copy link

While replacing Docker with Podman in our CI, the Docker Workflow plugin would hang trying to start the first process inside the container. As you said, adding -u 0:0 solved this issue, but I had some issues with deleting the workspace due to UID/GID mismatch. The solution that I found is to use --userns keep-id instead of -u 0:0. The --userns flag also plays well with -u x:y that Docker Workflow plugin passes to Docker by default.

@reda-alaoui
Copy link

reda-alaoui commented Jun 16, 2025

Exactly what we needed for docker rootless, thank you 🙏 Tested and validated :)
Could someone please review this?

@sschuberth
Copy link
Member

@jglick any chance to have a look?

@jglick
Copy link
Member

jglick commented Jul 7, 2025

@sschuberth no, I am not maintaining this plugin. In general, if it does not perfectly fit your needs the first time you try to use it, and every time thereafter, just do not use it. Run docker CLI commands from sh directly.

jglick and others added 23 commits July 21, 2025 10:20
Co-authored-by: Mark <MarkRx@users.noreply.github.com>
Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) from 5.5 to 5.7.
- [Release notes](https://github.com/jenkinsci/plugin-pom/releases)
- [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md)
- [Commits](jenkinsci/plugin-pom@plugin-5.5...plugin-5.7)

---
updated-dependencies:
- dependency-name: org.jenkins-ci.plugins:plugin
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The plugin BOM agents seem to have the `docker` command available but the
user running the agent is not authorized to use the `docker` command.
Previously that was detected by calling `docker ps` and detecting the
failure.

Restores a change made in

* jenkinsci#331

Testing done

Confirmed that I could see the same failure on a local computer as is seen on
https://ci.jenkins.io/job/Tools/job/bom/job/master/3968/testReport/org.jenkinsci.plugins.docker.workflow/DockerDSLTest/

The computer had Docker CE installed by the specific user running the
test did not have permission to access Docker.  Prior to this change,
the tests failed with the message:

CANNOT CONNECT TO THE DOCKER DAEMON AT UNIX:///VAR/RUN/DOCKER.SOCK. IS THE DOCKER DAEMON RUNNING?

After making this change, the tests pass on that computer with the
specific user that does not have permission to access Docker.
…88.v7fe26526366e (jenkinsci#345)

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) from 5.9 to 5.12.
- [Release notes](https://github.com/jenkinsci/plugin-pom/releases)
- [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md)
- [Commits](jenkinsci/plugin-pom@plugin-5.9...plugin-5.12)

---
updated-dependencies:
- dependency-name: org.jenkins-ci.plugins:plugin
  dependency-version: '5.12'
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@lnlrbr
Copy link
Author

lnlrbr commented Sep 16, 2025

@jglick: Asking thousands of users to update all their pipelines is simply not feasible. This plugin has become the de facto standard across many organizations. However, its current implementation grants excessive privileges, raising serious security concerns for the CI environment. For instance, as it stands, any user can mount the host’s /etc directory as a volume with full read/write access. The proposed change eliminates this vulnerability.

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.