Testcontainers version
3.8.0
Using the latest Testcontainers version?
Yes
Host OS
Windows
Host arch
x86
.NET version
8
Docker version
Client:
Cloud integration: v1.0.35+desktop.13
Version: 26.0.0
API version: 1.45
Go version: go1.21.8
Git commit: 2ae903e
Built: Wed Mar 20 15:18:56 2024
OS/Arch: windows/amd64
Context: default
Server: Docker Desktop 4.29.0 (145265)
Engine:
Version: 26.0.0
API version: 1.45 (minimum version 1.24)
Go version: go1.21.8
Git commit: 8b79278
Built: Wed Mar 20 15:18:01 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Docker info
Client:
Version: 26.0.0
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.13.1-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.26.1-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
debug: Get a shell into any image or container. (Docker Inc.)
Version: 0.0.27
Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.23
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.4
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.1.0
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scout: Docker Scout (Docker Inc.)
Version: v1.6.3
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 6
Server Version: 26.0.0
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.133.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 31.31GiB
Name: docker-desktop
ID: 224a3cbc-8590-4017-89ab-50c7ac65bf25
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=npipe://\\.\pipe\docker_cli
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profileWhat happened?
I'm using ImageFromDockerfileBuilder to build an image for an ASP.NET Core 8.0 project, then using ContainerBuilder to create a container for that image.
The container that gets produced by Testcontainers is different from the container produced by using docker directly to build the image then container.
Specifically, the files in the /app folder end up with different file permissions that are less permissive.
This causes the container to fail at startup with an error that ASP.NET cannot read appsettings.json due to lack of permissions.
.NET 8 has changed to build more secure containers, and it now uses a non-root user called app in the Dockerfile.
With the less permissive file permissions applied by Testcontainers, the non-root user app cannot read appsettings.json.
Changing the user back to root, as in earlier versions of .NET, resolves the problem.
Testcontainers shouldn't be producing files with different file permissions from the standard docker build as far as I can tell and there are no options to control this as far as I can tell. I haven't looked into it too deeply, but I saw mention in the docs that Testcontainers creates a tar of the files and then copies these in at some point. If so, I suspect that might be where the file permissions are being changed to less permissive values?
Relevant log output
No response
Additional information
No response
Testcontainers version
3.8.0
Using the latest Testcontainers version?
Yes
Host OS
Windows
Host arch
x86
.NET version
8
Docker version
Client: Cloud integration: v1.0.35+desktop.13 Version: 26.0.0 API version: 1.45 Go version: go1.21.8 Git commit: 2ae903e Built: Wed Mar 20 15:18:56 2024 OS/Arch: windows/amd64 Context: default Server: Docker Desktop 4.29.0 (145265) Engine: Version: 26.0.0 API version: 1.45 (minimum version 1.24) Go version: go1.21.8 Git commit: 8b79278 Built: Wed Mar 20 15:18:01 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0Docker info
What happened?
I'm using
ImageFromDockerfileBuilderto build an image for an ASP.NET Core 8.0 project, then usingContainerBuilderto create a container for that image.The container that gets produced by Testcontainers is different from the container produced by using docker directly to build the image then container.
Specifically, the files in the /app folder end up with different file permissions that are less permissive.
This causes the container to fail at startup with an error that ASP.NET cannot read appsettings.json due to lack of permissions.
.NET 8 has changed to build more secure containers, and it now uses a non-root user called app in the Dockerfile.
With the less permissive file permissions applied by Testcontainers, the non-root user app cannot read appsettings.json.
Changing the user back to root, as in earlier versions of .NET, resolves the problem.
Testcontainers shouldn't be producing files with different file permissions from the standard docker build as far as I can tell and there are no options to control this as far as I can tell. I haven't looked into it too deeply, but I saw mention in the docs that Testcontainers creates a tar of the files and then copies these in at some point. If so, I suspect that might be where the file permissions are being changed to less permissive values?
Relevant log output
No response
Additional information
No response