Error "/var/run/docker.sock: connect: permission denied" occurs when building an image using podman on Fedora with SELinux enabled

[simon-geard]

Short version - running bootBuildImage on a freshly created Spring Initializr project fails with the following:

$ ./gradlew bootBuildImage 
> Task :bootBuildImage
Building image 'docker.io/library/demo:0.0.1-SNAPSHOT'

 > Pulling builder image 'docker.io/paketobuildpacks/builder:base' ..................................................
 > Pulled builder image 'docker.io/paketobuildpacks/builder@sha256:d00e4cc8aa0f40d47e8b67bbd152436b9c89f96dbba46f6adf9d39777950d149'
 > Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' ..................................................
 > Pulled run image 'docker.io/paketobuildpacks/run@sha256:d1b1fb1c0549f92c0810382707155469753dda01b2a7722dfab4dd25859e543a'
 > Executing lifecycle version v0.14.1
 > Using build cache volume 'pack-cache-5cbe5692dbc4.build'

 > Running creator
    [creator]     ERROR: initializing analyzer: getting previous image: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied

> Task :bootBuildImage FAILED

This is a stock project, with no apart from the addition of Podman-configuration identical to the Gradle plugin docs...

Following some suggestions on Stack Overflow, I've tried building things with Pack using the following command:

$ export DOCKER_HOST=unix://$(podman info --format='{{.Host.RemoteSocket.Path}}')
$ ./pack build demo -p build/libs/demo-0.0.1-SNAPSHOT.jar -B paketobuildpacks/builder:base
# ... trimmed noise ...
ERROR: failed to build: executing lifecycle: failed to create 'creator' container: Error response from daemon: container create: statfs /var/run/docker.sock: permission denied

I'm not familiar with Pack, but I noticed the --docker-host command line option. And sure enough, appending --docker-host inherit to the previous command causes things to work perfectly. Or at least, build perfectly... the resulting image seems to have a bytecode version issue suggesting a Java mismatch, but that's a problem for later.

So my issue then is — what am I missing on the Spring Boot side for this to work?

If it matters, I've tested this with both Spring Boot 2.7.2, and the current 3.0.0 milestone, no difference. Here's the build.gradle file for reference:

plugins {
	id 'org.springframework.boot' version '2.7.2'
	id 'io.spring.dependency-management' version '1.0.12.RELEASE'
	id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

tasks.named('test') {
	useJUnitPlatform()
}

tasks.named("bootBuildImage") {
    docker {
        host = "unix:///run/user/1000/podman/podman.sock"
        bindHostToBuilder = true
    }
}

[scottfrederick]

@simon-geard Your configuration looks correct. I was able to reproduce the problem with a fresh Fedora installation.

The pack option --docker-host inherit and the Spring Boot plugin option docker.bindHostToBuilder = true should behave in the same way, and result in a bind mount from /var/run/docker.sock in the builder container to /run/user/1000/podman/podman.sock on the podman host. This binding is working properly in both cases.

The problem on Fedora is related to SELinux. The documented podman configuration works for me if I (temporarily) disable SELinux with sudo setenforce Permissive . pack is working because when it binds the sockets it also sets a security option that allows the binding to work in SELinux, as discussed in a pack issue.

We should set the same security option in the Spring Boot plugins to maintain compatibility with pack.

[simon-geard]

The problem on Fedora is related to SELinux. The documented podman configuration works for me if I (temporarily) disable SELinux with sudo setenforce Permissive.

Ah yes — you've identified the problem... with SELinux enforcement turned off, things work exactly as-documented on my machine.

That's something I can use as a temporary workaround, but what would it take to get a working out-of-the-box fix such as you describe? Anything I can help with?