Implement row-level access control by creating views - MaxCompute

Implement row-level access control by creating a filtered view or table per merchant, then sharing it through a package or direct grant. This guide covers the view-based approach (recommended) and the table-based alternative, using an order table shared across multiple merchants as the running example.

When to use this approach

MaxCompute also supports a native row-level access control feature designed for large-scale rule definitions. That feature eliminates per-user object creation and avoids redundant storage, but it can produce more complex query plans and comes with certain limitations described in the linked topic.

The view and table methods in this guide work well when each user needs their own filtering rule, the number of merchants is manageable, and you want simpler query plans based on pre-filtered data.

Choose a method

Method	How it works	Use when	Drawbacks
Views (recommended)	Create a filtered view per merchant; share via package or direct grant	Each merchant needs read-only access to their own rows with no extra storage cost	—
Tables	Create a filtered table per merchant	Each merchant needs their own isolated dataset	Data is duplicated; tables must stay in sync with the source table

Use views when read-only access to filtered rows is sufficient — this covers most multi-tenant reporting scenarios.

Use tables when downstream processes require writing to the filtered dataset, or when pre-aggregated snapshots are operationally necessary. Factor in the storage cost and synchronization overhead before choosing this approach.

Both methods create one object per merchant. At large scale, consider the native row-level access control feature, which handles rule definitions centrally without per-user object creation.

Scenario

The table_order table in Project A stores order transaction records for all merchants. All merchants can access the table, but each merchant must see only their own store's records. The sellerid column identifies the merchant, so a per-merchant filter on sellerid enforces row-level isolation.

Prerequisites

Before you begin, make sure you have:

An Alibaba Cloud account with access to Project A
The MaxCompute client installed and started
The merchant's project name and the Alibaba Cloud username to grant access to

Grant access through a package

Use a package to share the filtered view with the merchant's project. Packages are the standard MaxCompute mechanism for cross-project resource sharing.

Log on to the MaxCompute client using your Alibaba Cloud account.
Create a filtered view for the merchant in Project A. Replace sellerid='xxxx' with the merchant's actual seller ID.
```
create view <view_name> as select * from table_order WHERE sellerid='xxxx';
```
For view syntax and options, see View-related operations.

Create a package in Project A, add the view, and allow the merchant's project to install it.

-- Create a package.
create package <package_name>;
-- Add the view to the package.
add table <view_name> to package <package_name>;
-- Allow the merchant's project to install the package.
allow project <project_name> to install package <package_name>;

For background on cross-project sharing, see Cross-project resource access based on packages.

Switch to the merchant's project context, install the package, and grant the merchant's user read access.

-- Install the package in the merchant's project.
install package <Project A>.<package_name>;
-- Grant the user read permission on the package.
grant read on package <Project A>.<package_name> to user <user_name>;

Grant access directly

As an alternative to packages, grant SELECT and DESCRIBE permissions directly on the view. Use this approach when cross-project sharing is not required.

grant select,describe on table <view_name> to user <user_name>;