Skip to content

fix(runtime): SELinux-safe start on Podman, VM socket for Docker on desktops - #1495

Merged
Pijukatel merged 2 commits into
actor-runtimefrom
feat/runtime-start-selinux-and-vm-socket
Oct 13, 2026
Merged

Pijukatel merged 2 commits into
actor-runtimefrom
feat/runtime-start-selinux-and-vm-socket

Conversation

@Pijukatel

@Pijukatel Pijukatel commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

Two cases where apify runtime start produced a runtime that reported the engine as unavailable. Both surfaced on actor-runtime's macOS CI leg (apify/actor-runtime#65).

SELinux on Podman hosts

  • Under SELinux enforcing (Fedora, RHEL, and the Fedora-based VM of podman machine, so Podman Desktop on macOS and Windows), the runtime container may not connect to the engine's API socket bind-mounted into it: the socket carries the engine's label, not a container's.
  • podmanInfo now also reads Host.Security.SELinuxEnabled; buildRuntimeRunArgs adds --security-opt label=disable via the new runtimeSecurityOptions, next to runtimeNetworkMode.
  • Only the runtime container runs unconfined. The Actor containers it starts stay confined (verified by actor-runtime's dev-folder e2e under enforcing SELinux).

Docker socket on macOS and Windows

  • The daemon lives in a VM there and serves /var/run/docker.sock inside it on every desktop engine. A DOCKER_HOST unix socket is a host path (Colima's docs suggest exporting one for tools that ignore contexts), which a bind mount cannot carry into the VM.
  • resolveEngineSocketPath now consults DOCKER_HOST only on Linux.

Pijukatel and others added 2 commits October 13, 2026 08:32
…forces it

Under SELinux enforcing - Fedora and RHEL, and the Fedora-based VM of
`podman machine`, so Podman Desktop on macOS and Windows - the runtime
container may not connect to the engine's API socket bind-mounted into it:
the socket carries the engine's label, not a container's. The runtime does
everything through that socket, so `apify runtime start` produced a runtime
that reported the engine as unavailable.

`podmanInfo` now also reads `Host.Security.SELinuxEnabled`, and
`buildRuntimeRunArgs` adds `--security-opt label=disable` (via the new
`runtimeSecurityOptions`, next to `runtimeNetworkMode`) when it is set.
Only the runtime container runs unconfined; the Actor containers it starts
stay confined as before.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013oHHo44jxAVWrVrBvf2DBk
`resolveEngineSocketPath` now ignores `DOCKER_HOST` off Linux, so the
rootless-Docker case has to say which platform it means: on the Windows
runners it took the host platform and got the default socket back.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013oHHo44jxAVWrVrBvf2DBk
@Pijukatel
Pijukatel marked this pull request as ready for review October 13, 2026 09:18
@Pijukatel
Pijukatel merged commit 1d90d60 into actor-runtime Oct 13, 2026
38 of 41 checks passed
@Pijukatel
Pijukatel deleted the feat/runtime-start-selinux-and-vm-socket branch October 13, 2026 09:18
Pijukatel pushed a commit to apify/actor-runtime that referenced this pull request Oct 13, 2026
…art command

apify-cli's `buildRuntimeRunArgs` now adds `--security-opt label=disable` itself on Podman hosts with
SELinux enforcing (apify/apify-cli#1495), placed after the network mode. Move the suite's own
`extraRunArgs` escape hatch into the mirrored `runtimeRunArgs` at that same position, so the pinned
command is once again the CLI's verbatim, and pin the new shape in the unit test.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013oHHo44jxAVWrVrBvf2DBk
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants