Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for nonroot OCI images #1077

Closed
3 tasks done
kaniini opened this issue Aug 4, 2022 · 9 comments · Fixed by #4151
Closed
3 tasks done

Add support for nonroot OCI images #1077

kaniini opened this issue Aug 4, 2022 · 9 comments · Fixed by #4151
Labels
feature add new functionality
Milestone

Comments

@kaniini
Copy link

kaniini commented Aug 4, 2022

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

@aral
Copy link

aral commented Sep 19, 2022

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
Copy link

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
Copy link
Member

6543 commented Oct 29, 2022

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

@anbraten anbraten mentioned this issue Nov 26, 2022
31 tasks
@6543 6543 added feature add new functionality and removed enhancement improve existing features labels Dec 23, 2022
@janka102
Copy link

janka102 commented Jan 12, 2023

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

@qwerty287 qwerty287 added this to the 3.x.x milestone Nov 4, 2023
@pat-s
Copy link
Contributor

pat-s commented Nov 10, 2023

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

@vyskocilm
Copy link

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
Copy link
Member

6543 commented Jan 19, 2024

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

@ReIaxo
Copy link

ReIaxo commented Oct 14, 2024

Whats the state here? I have also permission problems with this image cimg/android:2024.04.1 while writing a file.

Will this be merged/fixed soon or should I search for a not rootless image? Or what is the recommended workaround?

@pat-s
Copy link
Contributor

pat-s commented Oct 22, 2024

See the linked PR. You can already use it via tag pull_4151. Not sure when /if it will be merged, nobody has done a review yet.

Note that doing so will update your DB schema version (if you're still on 2.7.1) which means you can't go back afterwards.

@6543 6543 closed this as completed in #4151 Nov 2, 2024
@qwerty287 qwerty287 modified the milestones: 3.x.x, 3.0.0 Nov 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature add new functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants