Fix permission denied error in Azure Pipelines#14534
Conversation
When we generate temporary dockerfiles, we are generating them directly under the TEMP directory. This can cause issues in some environments because docker build will walk all the files and folders next to the dockerfile as context to the build. For example, in AzDO pipelines, we can get an error like "ERROR: error from sender: lstat /tmp/.mount_azsec-KdAJKO: permission denied". To fix this, we generate the Dockerfile in a subdirectory of TEMP, so it is the only file passed as context to docker build. Fix #14523
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14534Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 14534" |
|
/deployment-test |
|
🚀 Deployment tests starting on PR #14534... This will deploy to real Azure infrastructure. Results will be posted here when complete. |
There was a problem hiding this comment.
Pull request overview
Adjusts how temporary Dockerfiles are created during container image builds to avoid Docker/buildx traversing the whole TEMP directory (which can trigger permission denied errors in hosted environments like Azure Pipelines).
Changes:
- Generate temporary Dockerfiles using
TempDirectory.CreateTempFile("Dockerfile")so they are placed in a dedicated empty temp subdirectory. - Apply this change to both Dockerfile-factory-based container builds and project image rebuilds that generate a temporary Dockerfile.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/Aspire.Hosting/ContainerResourceBuilderExtensions.cs | Creates generated Dockerfiles in an isolated temp subdirectory to reduce buildx context traversal issues. |
| src/Aspire.Hosting/ApplicationModel/ProjectResource.cs | Uses an isolated temp subdirectory for the generated Dockerfile used when layering container files. |
🎬 CLI E2E Test RecordingsThe following terminal recordings are available for commit
📹 Recordings uploaded automatically from CI run #22147281086 |
|
✅ Deployment E2E Tests passed Summary: 19 passed, 0 failed, 0 cancelled Passed Tests
🎬 Terminal Recordings
|
|
Can we add a test for this? |
|
The existing E2E CLI tests verify no regression. |
There isn't really a good way to test this. I can't even reproduce the error on my machine. Something about AzDO pipelines is creating unreadable files in the temp directory, causing the docker build to fail. I've verified the fix manually in AzDO pipelines. But not sure how to write an automated test for this. |
I approved because I was manually able to verify but, if we're targeting an automated test, could you create a scenario where the tmp folder has unrestricted permissions but other folders inside it have a different ownership or read/write policy. This should create a situation where the scan happens inside a folder it has access to but where it would then come across a subfolder it's not allowed to read. Just throwing an idea out there. |
* Fix permission denied error in Azure Pipelines When we generate temporary dockerfiles, we are generating them directly under the TEMP directory. This can cause issues in some environments because docker build will walk all the files and folders next to the dockerfile as context to the build. For example, in AzDO pipelines, we can get an error like "ERROR: error from sender: lstat /tmp/.mount_azsec-KdAJKO: permission denied". To fix this, we generate the Dockerfile in a subdirectory of TEMP, so it is the only file passed as context to docker build. Fix dotnet#14523
When we generate temporary dockerfiles, we are generating them directly under the TEMP directory. This can cause issues in some environments because docker build will walk all the files and folders next to the dockerfile as context to the build. For example, in AzDO pipelines, we can get an error like "ERROR: error from sender: lstat /tmp/.mount_azsec-KdAJKO: permission denied".
To fix this, we generate the Dockerfile in a subdirectory of TEMP, so it is the only file passed as context to docker build.
Fix #14523