RLS support

[vincent-lecrubier-skydio]

I wonder if you have any plans to support Row Level Security (RLS)?

Most uses of RLS at scale use a single user (or a few users corresponding to roles), and use SET LOCAL variables to describe the current user ID. See https://www.graphile.org/postgraphile/security/#how-it-works

So it would be a matter of:

• Having ways to make Electric-server add SET LOCAl variables when querying postgres
• Maybe supporting many shapes per table (one shape per user?)
• Dealing with real-time implications (Something like what Supabase does, running RLS on replication stream)

[KyleAMathews]

This definitely something we're interested in. Getting to a stable, scalable 1.0 is our immediate priority (we'll rely on APIs for auth until then) but we're keen to explore other options in the future including RLS.

[thruflo]

Just for some addition context, this is something we've looked into in some depth. Your summary is exactly right:

1. for queries and direct writes, we can use an auth context from the client connection and set local to provide this auth context to RLS rules
2. for ongoing replication the picture is a little more complex, because Electric uses a single replication stream and then fans out shapes to multiple clients

There are two primary approaches for solving (2):

a. find a way to use a replication stream per tenant / auth context; this can work for some data access patterns
b. find a way to apply RLS rules at the sync-service level

The second approach requires getting the rules and running them against the operations in the replication stream. This has a challenge, in that RLS rules are quite flexible/expressive and allow you to query the state of the database. For example, when authorising access to a row, you can query another table. This is challenging when processing the replication stream, because the replication stream is behind the current state of the database.

Postgres has MVCC internally but does not (natively) allow you to query the database at a particular snapshot. This means that by the time you have received a transaction in the replication stream, you can't query the database within the same snapshot. This limits the complexity of RLS rules that can be supported.

Possible solutions

1. gain the ability to query Postgres at a snapshot -- requires extensions / branching capability or changes to a data model; this can be unsupported, vendor specific and potentially slow to hydrate a branch-snapshot
2. support limited RLS rules that just use the row and auth context; this seems promising, as where necessary, triggers can be added to put necessary auth information in the row
3. use a replication stream per tenant / auth context

[lukvermeulen]

Especially as you're mentioning supabase, it would be cool if electric could just leverage RLS policies that are created in supabase already. This way an offline enabled app with electric + supabase could have quite a head start.

[thruflo]

One of the observations about the https://supabase.com/docs/guides/realtime/authorization design is that we could potentially support something similar, where RLS rules set on an electric.shapes table (or whatever) could be evaluated in the sync engine (or provided to an auth proxy or gatekeeper endpoint) when authorizing shape access. This could allow RLS to be used to power GET shape level auth. In our case, with the shape definition available rather than the channel topic.