-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Experiencing permission denied
after v3.1.0 on jobContainers when container user is not 'root'
#956
Comments
We experience the same issue with the v2.5.0 version, our CI is broken, had to rollback :( |
The same happens with latest release on actions/cache - the common denominator seems to the usage of actions/core 1.10.0. |
Anyone trying to fix this? |
Work around the issue raised in: actions/checkout#956 by setting the container user to root. Note that we don't want to do this more generally due to the configuration we use on the self-hosted builders.
Just brainstorming a bit here: would there be security implications if the runner were to set
I guess the core problem is Docker doesn't really support UID remaps at runtime itself. Nevertheless, this is a solution I was initially going to chase but the problem is that any mechanism to do so dynamically is disabled in GitHub Actions. While you could rely on a fixed 1001 for GitHub-hosted, it gets trickier with varying self-hosted setups. Initial idea I had was to create an entrypoint that would get the UID of |
Does anyone else have the same security concerns than me if I am forced to runs all Pipeline Stuff and Action under root in a container? I mean, it is a much higher security risk than using an unprivileged user which is just able to execute a bunch of commands it needs. |
I like this idea from @Bo98
@fhammerl Is this guaranteed to be a long-term contract that we could rely on in the future with subsequent actions upgrades? Or just one time working working workaround that's still unsupported path? Can you comment on the technical limitations for supporting container users? |
Is this issue progressing? |
The user id changed between In |
Revised paths Fixed reference format Try fixing env var injection Injecting GitHub secret into container Added visual help Injecting workspace path Fixed path to workspace Tried fixing permission issue Added continuous integration status badge Run tests continuously Run as root user Downgrading [checkout](actions/checkout#956) Trying 1001 instead of root first Upgraded checkout action Added job names Fixed test target Removed user option
pre-release check Commenting prover application temporarily for pre-release validation Fixed LaTeX results making target in continuous integration workflow Revised container image names First attempt to produce results archive on pull-request Declare dependency between release creation and Push docker image Installing dependencies without interaction Removed [environment variables setting from job container](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions\#setting-an-environment-variable) Write results to ./out directory Applied custom sort after parsing results Revised release workflow Revised working directory Revised archiving script Removed left workspace occurrences Added results to archive Injecting missing release name into job container Revise step name Revise intermediate success rate filename display Injecting missing release name into job container Try to avoid [untrusted state](https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands) Replace slashes with dashes Trying to replace `marvinpinto/action-automatic-releases@latest` with official action from GitHub Revise package updates Removed bash as default shell Install dependencies on image build Removed requirements details Trying to restore container initialization Revise step title Revise paths Commenting out prover application Revised paths Fixed reference format Try fixing env var injection Injecting GitHub secret into container Added visual help Injecting workspace path Fixed path to workspace Tried fixing permission issue Added continuous integration status badge Run tests continuously Run as root user Downgrading [checkout](actions/checkout#956) Trying 1001 instead of root first Upgraded checkout action Added job names Fixed test target Removed user option Align file owner uid / gid Removed test detecting missing FR locale from container
Revised paths Fixed reference format Try fixing env var injection Injecting GitHub secret into container Added visual help Injecting workspace path Fixed path to workspace Tried fixing permission issue Added continuous integration status badge Run tests continuously Run as root user Downgrading [checkout](actions/checkout#956) Trying 1001 instead of root first Upgraded checkout action Added job names Fixed test target Removed user option Align file owner uid / gid Removed test detecting missing FR locale from container
Probably because of actions/checkout#956
Suggested by actions/checkout#956
This limitation requiring workflow Docker containers to run as root is requiring contortions to work around (e.g., pgcentralfoundation/pgrx#1652), and to @romulus-ai's point, it seems like a potentially significant security issue. If there is some way to work around it, like using a specific UID and/or username like |
@theory Best regards |
Thanks @betimcariad. Seems like that might work okay until GitHub decides to change the UID and GID. :-( |
@theory Ah, I was mostly referring to selfhosted runners. I guess, you might be right about Github hosted runners. Officially, Github anyways says to use root inside the container... |
After the rollout
actions/checkout
v3.1.0, some reportedpermission denied
errors when using the action on a jobContainer running with a container user that is not 'root'. With v3.1.0, we're using commands that write to files to replace deprecated stdout commands.These are the files in question causing permission issues due to mismatched UIDs between user running the runner process and the user on the container it starts.
Running a container using a container user that is not 'root' is an unsupported path, we've listed some workarounds below.
Summary
In short: the jobContainers in these workflows seem to follow an unsupported path. Namely,
I believe the jobContainer operates as the user 'circleci' in the workflow you linked.
We will roll out the changes again as we haven't seen issues with the officially supported paths.
It is recommended 'not use the USER instruction in your Dockerfile'.
In most cases, this means 'run the container as root'.
I understand this introduces some friction, so see below for workarounds and a technical summary.
Detailed Summary
ubuntu-latest
, this user is 'runner' withUID-1001
). These files are then mounted to your jobContainer.actions/checkout
is a.js
file executed usingnode
on your jobContainer. As per the changes in1.
,actions/checkout@v3.1.0
attempts to write to these temp files on your jobContainer.This can have a couple of outcomes:
a) If the UID of the jobContainer user == UID of host runner user (
UID-1001
onubuntu-latest
): write is successfulb) If the UID of the jobContainer user != UID of host runner user (
UID-1001
onubuntu-latest
): permission deniedThe jobContainers in the above workflow seem to run into 2/b.
Fix
As per the docs, don't modify the default user in the Dockerfile. If that's not feasible for you: 👇
Workarounds (unsupported)
actions/checkout@v3.0.2
in your workflow (will be deprecated)Error logs
The text was updated successfully, but these errors were encountered: