Add support for nonroot OCI images

[kaniini]

Clear and concise description of the problem

I want to build my software using pipelines that use nonroot images, as my builds do not require root.

But Woodpecker today is very much built around the assumption that builds are done as root, for example hardcoding HOME=/root in the environment, and setting the permissions of the workspace to require root.

Suggested solution

Add something like

run-as: [uid]

and then set up the permissions and home directory appropriately based on the image configuration.

Alternative

No response

Additional context

No response

Validations

• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[aral]

Just ran into this issue while attempting to use a cimg/node image to build Kitten using Woodpecker on Codeberg.

Kitten is designed to build/run in an unprivileged account and will actually fail if it isn’t.

This feature would mean I could use Woodpecker on my project :)

Thank you for making/sharing Woodpecker + I hope to be able to play with it in the future :)

[stefangehn]

I tried my own unprivileged container images and ran into this as well. Using 0.15.5 at least a local run with woodpecker-cli exec seemed to somewhat work.

Dockerfile contents for the unprivileged user:

# Create unprivileged user
ARG user_id=1000
ARG user_name=ci

RUN useradd -d /home/$user_name -m -u $user_id -s /bin/bash $user_name

# Create base directory for Drone/Woodpecker with correct owner
RUN install -d -o $user_name /drone /woodpecker

USER $user_name
# FIXME: overridden by woodpecker
ENV HOME=/home/$user_name
WORKDIR /home/$user_name

To use such an image I added an initial command to reset HOME based on the user that is currently executing processes in the container:

pipeline:
  check:
    image: debian-customized:bullseye-slim
    commands:
      - export HOME="$(getent passwd $(id -u) | cut '-d:' -f6)"
      - env | sort

[6543]

1032 is the groundwork to fix this ... and other stuff

[janka102]

I recently also ran into this issue as well with a custom image that uses a non root user.

The information from this comment was helpful in figuring out that I needed to update the HOME environment variable.

I want to add that I found out the files and folders are also owned by root, so if you try to modify or create files it will give a Permission denied (os error 13) error. And to fix this you can run chown -R UID:GID . in a previous step and that will update all the files for all later steps.

If your user in the container doesn't have sudo access then you will need to use another image that defaults to root. The ubuntu or alpine image should be fine. So something like the following worked for me:

pipeline:
  fix-ownership:
    image: ubuntu
    commands: chown -R 1000:1000 .

  build:
    image: my-non-root-image
    commands:
      - export HOME="$(getent passwd $(id -u) | cut '-d:' -f6)"
      - make build

[pat-s]

Another report here: https://codeberg.org/Codeberg-CI/feedback/issues/141

[vyskocilm]

It'd be great if a helm installation for k8s allows non root volumes too. Right now securityContext and WOODPECKER_BACKEND_K8S_SECCTX_NONROOT: true ensures the pods runs as non root, yet the mounted volume is writable for a root user only.

[6543]

The file permissions on the volume(s) are the blocking issue here ...

my thought: woud setting acls that just enforce similar to chmod -R 777 . could do it but still preserve the unix permissions (in case a build artifact depend on it) ... ?