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

windocker: Merge or otherwise mitigate "dubious ownership" remediation #3713

Closed
sxa opened this issue Aug 14, 2024 · 2 comments · Fixed by adoptium/ci-jenkins-pipelines#1099
Assignees
Labels
docker os:windows secure-dev Issues specific to SSDF/SLSA compliance work

Comments

@sxa
Copy link
Member

sxa commented Aug 14, 2024

I have not yet been able to identify 100% when the scenario occurs, but I've seen it in two places. One on the host system, and one just before the git clean -fdx operation in the pipelines.

I suspect the problems we're seeing are caused by the Windows SID (User ID) on the host and container being different which causes git to think the directories and files are owned by someone else. This can be mitigated by a .gitconfig file which is stored in the location pointed to by the HOME environment variable (Currently C:\jw which is volume mounted inside the build containers):

[safe]
        directory  *

This was not always working when I had it set to a more specific location such as /cygwin64/c/jw/workspace/build-scripts/jdk21u/windbld hence the current use of the * wildcard.

Note that this still does not appear to be working in all situations - potentially when a new docker images is created and a new SID is defined which affects the ownership of the .gitconfig itself, but this is just speculation and requires further investigation.

The .gitconfig change is not always working, so I have been running the windbld job from a pipelines branch that has a git config change to add the directory explicitly before the git clean -fdx, although I've also seen the same error earlier in the process (while it us doing work on the workspace on the host before the docker container).

@sxa
Copy link
Member Author

sxa commented Aug 19, 2024

The attempt to use .gitconfig in C:\jw isn't working. If Iissue a git config --global -l from within the workflow I get a failure:

12:22:29  + git config --global -l
12:22:29  fatal: unable to read config file '/cygdrive/c/jw/.gitconfig': No such file or directory

If I issue that immediately after adding a safe.directory parameter with git config then it shows the correct value so it's using a git configuration from elsewhere at that point.

If I move it out of the way then it fails earlier in the pipeline:

12:47:36  [CHECKOUT] Checking out User Pipelines https://github.com/sxa/ci-jenkins-pipelines.git : windows_docker_support
[Pipeline] checkout
12:47:36  The recommended git tool is: git
12:47:36  No credentials specified
12:47:36  Warning: JENKINS-30600: special launcher org.jenkinsci.plugins.docker.workflow.WithContainerStep$Decorator$1@1f132a55; decorates hudson.plugins.cygpath.CygpathLauncherDecorator$1@cef8bfd will be ignored (a typical symptom is the Git executable not being run inside a designated container)
12:47:36  Cloning the remote Git repository
12:47:36  ERROR: Error cloning remote repo 'origin'
12:47:36  hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- https://github.com/sxa/ci-jenkins-pipelines.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:

So for now it seems that this gitconfig file, and whatever it's using when I explicitly add in the safe.directory setting, are both required, so I'll leave both in place. Note that before I set the safe.directory options I have configured that the HOME variable is set to the jw directory via a sh -c set command.

@sxa sxa self-assigned this Aug 20, 2024
@sxa sxa added this to the 2024-08 (August) milestone Aug 20, 2024
@sxa sxa moved this to In Progress in 2024 3Q Adoptium Plan Aug 20, 2024
@sxa sxa moved this from In Progress to Done in 2024 3Q Adoptium Plan Aug 20, 2024
@sxa sxa added the secure-dev Issues specific to SSDF/SLSA compliance work label Aug 22, 2024
@sxa
Copy link
Member Author

sxa commented Aug 28, 2024

The current jobs are failing to remove some of the files after the build. Suspect they're being extracted via the host system and then deletion is attempted in the container which is failing:


18:29:42  Cleaning workspace non-hidden files: C:/workspace/openjdk-build/*
[Pipeline] sh
18:29:44  + rm -rf C:/workspace/openjdk-build/CONTRIBUTING.md C:/workspace/openjdk-build/FAQ.md C:/workspace/openjdk-build/LICENSE C:/workspace/openjdk-build/NOTICE C:/workspace/openjdk-build/README.md C:/workspace/openjdk-build/cyclonedx-lib C:/workspace/openjdk-build/docs C:/workspace/openjdk-build/pipelines C:/workspace/openjdk-build/tools C:/workspace/openjdk-build/workspace
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/CONTRIBUTING.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/FAQ.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/LICENSE': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/NOTICE': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/README.md': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/cyclonedx-lib': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/docs': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/pipelines': Permission denied
18:29:44  rm: cannot remove 'C:/workspace/openjdk-build/tools': Permission denied
[Pipeline] }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docker os:windows secure-dev Issues specific to SSDF/SLSA compliance work
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant