[enhancement]: Add option to skip GrantContainerUserSUDOPrivilege in job container init

[joshchngs]

Describe your feature request here

I would like to be able to skip this section, per container definition:

azure-pipelines-agent/src/Agent.Worker/ContainerOperationProvider.cs

Lines 636 to 646 in 0b8aefd

	executionContext.Output(StringUtil.Loc("GrantContainerUserSUDOPrivilege", containerUserName));
	// Create a new group for giving sudo permission
	string sudoGroupName = "azure_pipelines_sudo";
	await DockerExec(executionContext, container.ContainerId, $"groupadd {sudoGroupName}");
	// Add the new created user to the new created sudo group.
	await DockerExec(executionContext, container.ContainerId, $"usermod -a -G {sudoGroupName} {containerUserName}");
	// Allow the new sudo group run any sudo command without providing password.
	await DockerExec(executionContext, container.ContainerId, $"su -c \"echo '%{sudoGroupName} ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers\"");

If my image user already has sudo privilege, these steps are unnecessary. If I define the container with --user <something> they can't work. I want to be able to tell the agent that I've already handled setting up sudo for the job user.

Why?

The documentation says that the container user must be able to run these commands. In reality, only root can do this, as su will prompt for a password otherwise. Therefore, it is only possible to use images with USER=root.

Side note, I don't understand the /etc/sudoers write. This file should be read-only (mode 0440), and AFAIK it is in most base images. I don't understand how this command ever succeeds.

There are a few use cases where USER=root is not possible, including mine. The highlighted docker execs are the root cause, and are mentioned in a few places.

• https://github.com/MicrosoftDocs/azure-devops-docs/issues/5672
• Can't acquire root on common container distros #2043 (comment)
• https://stackoverflow.com/questions/73709965/azure-devops-container-pipeline-job-is-trying-to-redundantly-give-user1000-sudo
• https://stackoverflow.com/questions/54479666/docker-error-useradd-cannot-lock-etc-passwd?rq=4

Workarounds

The links above mention a few workarounds, such as passing --user 0:0 as a docker create option. This doesn't work for all use cases.

I'm currently doing:

Dockerfile

RUN chmod u+s /usr/sbin/groupadd /usr/sbin/usermod && \
    chmod u+w /etc/sudoers
COPY su_hack.sh /bin/su

su_hack.sh

#!/usr/bin/env bash
echo "'su' has been disabled in this container"

Caveats

The use case enabled by adding the option is only viable if the image already has a correctly configured user with matching UID/GID for the container init step to find. This means that either the agent host user UID/GID needs to be controlled, or the image needs to be rebuilt on each agent before it's used.

[vmapetr]

Hi, @joshchngs thanks for reporting!
We are currently working on more prioritized issues but will get back to this one soon.

[pixdrift]

Thanks for raising this issue, I think this whole block of code that interacts with and modifies the container needs discussion, it causes us no end of issues when running generic container images.
https://github.com/microsoft/azure-pipelines-agent/blob/master/src/Agent.Worker/ContainerOperationProvider.cs#L544-L764

I think more 'configuration knobs' to turn off the agent behaviour around creation, initialisation, and execution of containers, including this entire block of code would be a useful addition.

The agent always mounting in the docker.socket (or all the bind mounts for that matter) should probably be optional too!

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[joshchngs]

@vmapetr I think your bot is throwing shade. Any progress?

[asad26]

Any update on this. When can we have such feature?
Thanks