woodpecker icon indicating copy to clipboard operation
woodpecker copied to clipboard

Add support for nonroot OCI images

Open kaniini opened this issue 2 years ago • 9 comments

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.

kaniini avatar Aug 04 '22 23:08 kaniini

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 :)

aral avatar Sep 19 '22 14:09 aral

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

stefangehn avatar Oct 29 '22 18:10 stefangehn

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

6543 avatar Oct 29 '22 22:10 6543

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

janka102 avatar Jan 12 '23 20:01 janka102

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

pat-s avatar Nov 10 '23 09:11 pat-s

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.

vyskocilm avatar Jan 19 '24 17:01 vyskocilm

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) ... ?

6543 avatar Jan 19 '24 21:01 6543