JENKINS-74995 Add rootless support

[lnlrbr]

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]

+1

[imoazeem]

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

[concatime]

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]

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

[sschuberth]

@jglick any chance to have a look?

[jglick]

@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.

[lnlrbr]

@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.

[petermbauer]

We would also greatly appreciate if we could continue using this plugin in our company after switching to rootless Docker.

@lnlrbr some tests seem to be failing, is this an issue of the CI or is there something left to do?

@jglick i fail to understand your point. Almost anything can also be done with CLI commands but as we all know, the devil lies in the details, so getting it right is not as easy as it sounds in the first place. Apparently you were contributing to this plugin, but if this is not the case anymore, maybe @basil or @dwnusbaum can help out (i just tried to find some contributors based on merged PRs)?
Or is there something fundamentally wrong with the changes, or some reason for not supporting rootless setups?

[jglick]

Almost anything can also be done with CLI commands but as we all know, the devil lies in the details, so getting it right is not as easy as it sounds in the first place.

Exactly. And a prepackaged version purporting to support everyone’s use cases perfectly is far harder.

maybe […] can help out

I would not count on it.

[petermbauer]

Almost anything can also be done with CLI commands but as we all know, the devil lies in the details, so getting it right is not as easy as it sounds in the first place.

Exactly. And a prepackaged version purporting to support everyone’s use cases perfectly is far harder.

I would agree if this was about some additional niche feature, but adapting to an improvement of the underlying tool does not fall into this category.
However, it seems there is already a lot of negativity in the air here and you made up your mind, so it is what it is.

[lnlrbr]

@petermbauer I've tried to rebase my fork from the base branch but for some reasons Github doesn't like it. At the same time, if proposals are not even considered and are treated with contempt, why bother?

[jglick]

If someone would like to adopt the plugin, nobody is stopping you. This would mean committing to maintaining it: triaging issues and PRs, understanding the broad range of potential use cases that people have tried over the years that must be maintained for compatibility, testing routinely on different platforms which are not friendly to the sort of automated tests we can run on ci.jenkins.io, etc.