fix: db test on SELinux enabled systems

[avallete]

What kind of change does this PR introduce?

This PR adds the :z flag to the volume binding for SELinux systems when using the supabase db test command.

Fixes #2659

What is the current behavior?

When running supabase db test on a system with SELinux enabled, pg_tap fails to execute because the /tmp volume does not have the appropriate permissions, causing issues with the bind mount.

What is the new behavior?

With this change, the :z flag ensures the /tmp volume is properly relabeled to allow pg_tap to run successfully on SELinux-enabled systems. There are no expected impacts on systems where SELinux is not enabled.

Additional context

I'm hesitant about applying this change across all volume bindings in the CLI codebase. While this should fix the issue for SELinux users without affecting other systems, there might be security concerns, especially for "dynamic" bindings where the exact directory being mounted is unpredictable. Since this change is intended for local development, the security impact should be minimal, but I’m open to feedback on whether this is the best approach.

[coveralls]

Pull Request Test Coverage Report for Build 10906052517

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage remained the same at 60.091%

---

Files with Coverage Reduction	New Missed Lines	%
internal/storage/rm/rm.go	2	89.53%

Totals
Change from base Build 10897542975:	0.0%
Covered Lines:	6443
Relevant Lines:	10722

---

💛 - Coveralls

[avallete]

Made the changes to scope the z flags to Linux with SELinux installed environments only.

Changed the volume binding option across the codebase instead of just for the db test command.

[sweatybridge]

I'm not fully convinced about the scope of this change. We use different docker volume mount types, including named, anonymous, and bind mounts. Perhaps it's only bind mount that's breaking in selinux rather than every mount type.

Therefore, I think it's worth setting up a selinux test to reproduce this error, and to find out if other commands like functions deploy also need to be fixed.

There's also the alternative to disable selinux for a specific container which should be fine for running db tests https://jaosorior.dev/2018/selinux-and-docker-notes/

P.S. We probably need to use bitbucket which supports fedora runner https://bitbucket.org/supabase-cli/setup-cli/src/master/bitbucket-pipelines.yml

[avallete]

Setting up testing before making changes indeed sounds like a better plan. Plus it'll add coverage for one more platform, I'll do that, thank's for pointing in the right direction.

Edit:

I've tried to setup a fedora pipeline with SELinux enabled on bitbucket, sadly it seems that since the host doesn't have it enabled I can't do such things:

I've looked around and it seems like except self-hosted runners there is no easy ways to get this setup under CI/CD. But that's a whole other scope level.

In the meantime I'll try to setup a VM with fedora and SELinux enabled, and see if disabling selinux via volume flag seems to do the trick for db test.

[avallete]

I was able to reproduce the issue locally on a virtual machine. The SecurityOpt option mentioned in the article you linked, @sweatybridge, successfully resolves the problem with the db test run.

However, I wasn't able to find a way to test this in a CI environment. Interestingly, the tests passed in my reproduction environment as well, likely due to our use of mocked filesystems and Docker.

I encountered a separate issue related to an invalid RLIMIT_NOFILE when running both the storage and realtime containers. This seems like a distinct problem that should be addressed independently.

[sweatybridge]

Amazing, thank you for going the extra mile to reproduce this.

Is the rlimit issue a warning or straight error starting storage container? Either way, I'm happy to deal with that separately.