I am using RLS (Row Level Security) with supabase.io for a "serverless" application. I have to use various security definer functions for RLS policies. These are still callable through supabase's rpc library. Is there anyway to limit calling these functions to either the admin (me) or when used as part of a RLS policy?

e.g.:

CREATE OR REPLACE FUNCTION get_bases_editable_or_viewable_for_user(user_id uuid, allow_edit bool)
returns setof bigint as $$
  select base_id
  from access_controls
  where access_controls.user_id = $1 AND ($2 AND access_controls.access_level = 'editor') OR access_controls.access_level = 'viewer';
$$ stable language sql security definer;

CREATE policy "Users can read bases they are editors or viewers of"
on public.bases
for select using ( bases.id in (get_bases_editable_or_viewable_for_user(auth.uid(), true)) );

get_bases_editable_or_viewable_for_user allows any user, once they have another user's UID, to find out the UIDs that this user has access to as an editor or viewer:

supabase.rpc(
  "get_bases_editable_or_viewable_for_user",
  { user_id: "dddddde6-1111-4bdf-aaaa-33336ccc31ee", allow_edit: true }
)
.then(console.log) // => bad

Minimising opportunities for leaking information is always important for maximising the security of an application and the privacy of its users.

CodePudding user response：

You cannot restrict permissions on the function in that way, since the user that runs the query must be able to execute it.

I see two ways to improve that:

• Omit the first parameter from the function, so that it only gives results for the current user. Then nobody can see information for other users.

• In addition to the above, you could pass bases.id as a function parameter and have the function return a boolean. Then you cannot get a list, but the performance may suffer, since the function has to be called for each row.