Skip to content

SELinux blocks CLI-generated pg-delta CA bind mount with rootless Podman #5989

Description

@malsuryc

Affected area

Database

Supabase CLI version

v2.110.0

Operating system

Fedora 44

Installation method

npm

Command

export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
supabase db pull

Actual output

The image-pull progress is omitted below. The command otherwise ran with no custom migrations or configuration changes and failed during the default pg-delta schema diff:


Initialising login role...
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...
Diffing schemas...
Trying to pull public.ecr.aws/supabase/edge-runtime:v1.74.2...
...
error diffing schema: error running script:
Error: Failed to read certificate file '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt': EACCES: permission denied, open '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt'
	 at getCertValue (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/ssl-config.js:44:27)
	 at async parseSslConfig (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/ssl-config.js:62:23)
	 at async createManagedPool (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/postgres-config.js:340:23)
	 at async resolvePool (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:48:29)
	 at async resolveCatalog (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:63:26)
	 at async createPlan (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.32/dist/core/plan/create.js:71:27)
	 at async file:///var/tmp/sb-compile-edge-runtime/index.ts:52:18
PGDELTA_SCRIPT_ERROR
runtime has escaped from the event loop unexpectedly: event loop error: Error
	 at file:///var/tmp/sb-compile-edge-runtime/index.ts:96:9
main worker has been destroyed
event loop error: Error
	 at file:///var/tmp/sb-compile-edge-runtime/index.ts:96:9
Try rerunning the command with --debug to troubleshoot the error.
Exit Code: 1


The generated CA file was mode `0644`, but had the normal workspace SELinux type `user_home_t`. The helper container runs with the `container_t` domain, so SELinux rejects the read despite the Unix permissions.

Expected behavior

supabase db pull should complete with its default diff engine when the CLI is connected to a rootless Podman Docker-compatible socket on an SELinux-enforcing host. It should not require the user to relabel CLI-generated temporary artifacts manually.

Steps to reproduce

  1. keep SELinux enforcing
  2. systemctl --user start podman.socket, ensure it is rootless
  3. Point CLI at Podman socket, e.g. export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
  4. supabase db pull
  5. pg-delta Edge Runtime helper cannot read the CLI-generated supabase/.temp/pgdelta/pgdelta-target-ca.crt file and exits with EACCES

Crash report ID

No response

Docker and service versions

Podman `5.8.4`

Additional context

The following is AI slop

This is an SELinux labeling issue, rather than a Unix file-permission issue. As a scoped local workaround, relabeling only the ignored CLI temporary directory lets the local database initialization progress past an analogous pg_sodium secret-read failure:

chcon -Rt container_file_t supabase/.temp

For db pull specifically, the documented alternative diff engine also succeeds:

supabase db pull --diff-engine migra

A separate supabase start attempt encountered the same class of failure for a CLI-generated file under supabase/.temp/start-secrets/.../secret-0, bind-mounted read-only as /etc/postgresql-custom/pgsodium_root.key. This suggests the problem is shared handling of CLI-owned temporary bind-mount sources; the db pull reproduction above is the smallest observed case.

Could the CLI use an SELinux-compatible mount strategy for its own generated temporary files when using Podman, or avoid host bind mounts for this certificate material? The scope should remain limited to CLI-created files rather than applying a label change to arbitrary project source directories.

Related but not duplicates:

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions