RLS Business Access
L3
PostgresSecurity
Implement Row Level Security policies for social platform with proper access control for posts, comments, and channels.
Created by Fanshi Zhang
2025-08-17
Security And Access ControlStored Procedures And FunctionsSchema Design
Model Ranking
Click on the dots to view the trajectory of each task run
Task State
Table "users" {
"id" uuid [pk, not null, default: `gen_random_uuid()`]
"username" varchar(50) [unique, not null]
"email" varchar(100) [unique, not null]
"is_public" bool [default: false]
"created_at" timestamp [default: `CURRENT_TIMESTAMP`]
Indexes {
is_public [type: btree, name: "idx_users_is_public"]
}
}
Table "channels" {
"id" uuid [pk, not null, default: `gen_random_uuid()`]
"name" varchar(100) [not null]
"description" text
"is_public" bool [default: true]
"owner_id" uuid
"created_at" timestamp [default: `CURRENT_TIMESTAMP`]
Indexes {
is_public [type: btree, name: "idx_channels_is_public"]
owner_id [type: btree, name: "idx_channels_owner_id"]
}
}
Table "channel_moderators" {
"channel_id" uuid [not null]
"user_id" uuid [not null]
"created_at" timestamp [default: `CURRENT_TIMESTAMP`]
Indexes {
(channel_id, user_id) [type: btree, name: "channel_moderators_pkey"]
(channel_id, user_id) [type: btree, name: "idx_channel_moderators_channel_user"]
user_id [type: btree, name: "idx_channel_moderators_user"]
}
}
Table "posts" {
"id" uuid [pk, not null, default: `gen_random_uuid()`]
"channel_id" uuid
"author_id" uuid
"title" varchar(200) [not null]
"content" text
"created_at" timestamp [default: `CURRENT_TIMESTAMP`]
"updated_at" timestamp [default: `CURRENT_TIMESTAMP`]
Indexes {
author_id [type: btree, name: "idx_posts_author_id"]
channel_id [type: btree, name: "idx_posts_channel_id"]
created_at [type: btree, name: "idx_posts_created_at"]
}
}
Table "comments" {
"id" uuid [pk, not null, default: `gen_random_uuid()`]
"post_id" uuid
"author_id" uuid
"content" text [not null]
"created_at" timestamp [default: `CURRENT_TIMESTAMP`]
"updated_at" timestamp [default: `CURRENT_TIMESTAMP`]
Indexes {
author_id [type: btree, name: "idx_comments_author_id"]
created_at [type: btree, name: "idx_comments_created_at"]
post_id [type: btree, name: "idx_comments_post_id"]
}
}
Ref "channel_moderators_channel_id_fkey":"channels"."id" < "channel_moderators"."channel_id" [delete: cascade]
Ref "channel_moderators_user_id_fkey":"users"."id" < "channel_moderators"."user_id" [delete: cascade]
Ref "channels_owner_id_fkey":"users"."id" < "channels"."owner_id" [delete: cascade]
Ref "comments_author_id_fkey":"users"."id" < "comments"."author_id" [delete: cascade]
Ref "comments_post_id_fkey":"posts"."id" < "comments"."post_id" [delete: cascade]
Ref "posts_author_id_fkey":"users"."id" < "posts"."author_id" [delete: cascade]
Ref "posts_channel_id_fkey":"channels"."id" < "posts"."channel_id" [delete: cascade]
Instruction
Implement Row Level Security (RLS) policies for a social media platform with Users, Posts, Comments, and Channels.
Your Mission:
Build RLS policies for a social platform where users create posts and comments in channels. Implement proper access control so users can manage their own content, while channel moderators can moderate content in their channels.
RLS Requirements:
1. Users Table Access Rules:
- SELECT: Users can read all public user profiles (username, created_at)
- UPDATE: Users can only modify their own profile
- DELETE: Users can only delete their own account
2. Channels Table Access Rules:
- SELECT: Everyone can read public channel information
- INSERT: Any authenticated user can create a channel (becomes owner)
- UPDATE: Only channel owners can modify channel details
- DELETE: Only channel owners can delete channels
3. Posts Table Access Rules:
- SELECT: Users can read all posts in channels they have access to
- INSERT: Authenticated users can create posts in any channel
- UPDATE: Post authors OR channel moderators OR channel owners can edit posts
- DELETE: Post authors OR channel moderators OR channel owners can delete posts
4. Comments Table Access Rules:
- SELECT: Users can read comments on posts they can access
- INSERT: Authenticated users can comment on posts they can see
- UPDATE: Comment authors OR post authors OR channel moderators OR channel owners can edit comments
- DELETE: Comment authors OR post authors OR channel moderators OR channel owners can delete comments
5. Channel Moderators Table Access Rules:
- SELECT: Users can see moderator lists for channels
- INSERT: Only channel owners can add moderators
- DELETE: Channel owners can remove moderators; moderators can remove themselves
Session Context:
Use current_setting('app.current_user_id') to get the current user ID from session context.
Schema Requirements:
- Use only the
publicschema for all tables, functions, and policies - All helper functions should be created in the
publicschema - Do not create additional schemas
Expected Deliverables:
- Enable RLS on all five tables
- Create policies for SELECT, INSERT, UPDATE, DELETE operations on each table
- Helper functions to check permissions efficiently:
is_channel_owner(channel_id, user_id)is_channel_moderator(channel_id, user_id)can_moderate_channel(channel_id, user_id)
- Proper indexing to ensure RLS policies perform well
Test Scenarios:
Your RLS implementation will be verified with:
- Content ownership: Users can only edit their own posts/comments
- Moderation hierarchy: Moderators can moderate content in their channels
- Channel isolation: Users only see content from accessible channels
- Permission escalation: Owners have full control over their channels
- Cross-table access: Comment policies respect post and channel permissions
Success Criteria:
- Users can manage their own content (posts, comments)
- Channel owners have full control over their channels
- Moderators can moderate content in their assigned channels
- No unauthorized access to other users' private data
- Policies are efficient and don't create performance bottlenecks
- All operations (SELECT, INSERT, UPDATE, DELETE) are properly secured
Verify
Python