前言

对于数据库安全而言，用户权限隔离是守护数据访问边界、杜绝未授权操作的核心能力。KingbaseES 作为面向企业的专业数据库产品，一方面通过兼容 MySQL 核心语法简化迁移流程，另一方面突破基础兼容局限，完成了向“功能增强”阶段的升级。依靠用户权限隔离功能为普通用户提供表、函数、视图、字段等数据库对象的精细化访问管控，以权限隔离筑牢数据安全防线。

在这里插入图片描述

文章目录

一、用户权限隔离核心概述

1.1 功能定位与价值

KingbaseES 的用户权限隔离功能，核心目标是让普通用户仅能查看和操作已获得授权的数据库对象，未授权对象对用户“不可见”——既无法通过查询语句获取，也无法在数据库工具（如 KStudio）中看到，从根源上杜绝越权访问风险。

这个功能主要依赖 security_utils 插件实现，开启后会对数据库中具有 ACL（访问控制列表）字段的系统表统一配置 RLS 策略，通过 RLS 筛选逻辑过滤未授权对象，确保数据访问的安全性与合规性。

1.2 核心语法：启用与禁用

如果我们想针对数据库级开启或禁用用户权限隔离功能，只需要俩行代码即可解决。

-- 启用用户权限隔离
ALTER DATABASE database_name ENABLE OBJECT ISOLATION;

-- 禁用用户权限隔离
ALTER DATABASE database_name DISABLE OBJECT ISOLATION;

二、功能实现原理

2.1 底层依赖：行级安全策略（RLS）

这个功能实现主要依赖行级安全策略（Row-Level Security, RLS）,通过修改数据库状态，为当前数据库具有ACL字段的系统表统一添加配置好的RLS，通过RLS筛选以实现普通用户只能查看有权访问的对象（表、函数、视图、字段等）的目的。

在这里插入图片描述

  1. 功能开启时，数据库自动修改系统状态，为 sys_class（表对象）、sys_database（数据库对象）、sys_trigger（触发器对象）等带 ACL 字段的系统表，统一添加预设的 RLS 策略；
  2. 普通用户执行查询时，RLS 策略会自动筛选出该用户具有访问权限的对象，未授权对象直接从查询结果中过滤，实现“权限即所见”。

在这里插入图片描述

2.2 关键技术组件

2.2.1核 心结构体与列表

KingbaseES 为统一管理 RLS 策略， 定义了 CreateRLSForSystemTable 结构体与 CreateRLSForSystemTableList 列表，以此用于记录每条 RLS 的属性与全局策略集合：

// CreateRLSForSystemTable 结构体：记录单条 RLS 策略属性
typedef struct CreateRLSForSystemTable {
    int sysTabID;          // 系统表 OID
    char* relName;         // 系统表名称
    char* policyName;      // RLS 策略名称
    char* funcName;        // 权限判断函数
    char* schemaName;      // 权限判断函数所属模式
    char* relColname1;     // 权限判断函数参数1
    char* relColname2;     // 权限判断函数参数2
    char* privType;        // 支持的权限列表（如 select,insert,update）
} CreateRLSForSystemTable;

// CreateRLSForSystemTableList 列表：维护所有系统表的 RLS 策略
static const CreateRLSForSystemTable CreateRLSForSystemTableList[SYSTABLE_POLICY_MAXNUM] = {
    // 为 sys_class 表（rel）创建 RLS 策略，依赖 is_object_inclass 函数
    {RelationRelationId, "rel", "sys_class_isolation_object_rls", 
     "is_object_inclass", "security_utils", "currentuser", "oid", 
     "select,insert,update,delete,truncate,references,trigger,dumptable"},
    // 为 sys_database 表（db）创建 RLS 策略，依赖 has_database_privilege 函数
    {DatabaseRelationId, "db", "sys_database_isolation_object_rls", 
     "has_database_privilege", "pg_catalog", "current_user", "datname", 
     "connect,create,temporary,temp"},
    // 为触发器表（_trigger）创建 RLS 策略，依赖 has_trigger_privilege 函数
    {TriggerRelationId, "trge", "sys_trigger_isolation_object_rls", 
     "has_trigger_privilege", "security_utils", "currentuser", "oid", "execute"}
};
2.2.2 权限判断函数

对于不同数据库对象的权限校验，依赖专属的权限判断函数，比如：

  • 数据库对象：has_database_privilege（校验用户对数据库的连接、创建等权限）；
  • 表/序列对象：has_class_privilege_name_id（校验 select、dumptable 等权限）；
  • 触发器对象：has_trigger_privilege（校验用户对触发器的执行权限）。

以 has_class_privilege_name_id 为例，其核心逻辑是校验用户输入的权限是否在预设权限集合内，避免非法权限请求：

Datum has_class_privilege_name_id(KDB_FUNCTION_ARGS) {
    Name username = KDB_GETARG_NAME(0);       // 用户名
    Oid classoid = KDB_GETARG_OID(1);         // 对象 OID
    text* priv_type_text = KDB_GETARG_TEXT_PP(2);  // 请求权限类型
    char* priv_type_string = text_to_cstring(priv_type_text);
    
    // 预设表/序列支持的权限集合（含新增的 DUMPTABLE 权限）
    char* priv_type_string_table = "select,insert,update,delete,truncate,references,trigger,dumptable";
    char* priv_type_string_sequence = "select,update,usage";
    char priv_type[1024] = {'0'};
    
    // 校验请求权限是否合法
    if (strstr(priv_type_string, priv_type_string_table) == NULL && 
        strstr(priv_type_string, priv_type_string_sequence) == NULL) {
        ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                        errmsg("unrecognized privilege type: %s", priv_type_string)));
    }
    
    // 后续权限校验逻辑（略）
    KDB_RETURN_BOOL(true);
}

三、用户权限隔离实战操作

3.1 基础配置：启用权限隔离与验证

下面我们就以“普通用户 u1 访问表 t1”为例，演示权限隔离的启用、效果验证与权限授予流程：

步骤 1：环境准备（创建表与用户）
-- 1. 以 system 用户连接数据库，创建测试表 t1
test=# create table t1(a int);
CREATE TABLE

-- 2. 创建普通用户 u1（密码需符合复杂度要求）
test=# create user u1 with password '12345678ab';
CREATE ROLE
步骤 2：未开启隔离时的访问测试
-- 以 u1 身份连接数据库，查询表 t1
test=# \c -u1
您现在以用户名"u1"连接到数据库"test"

-- 查询 sys_class 系统表，可看到 t1（未隔离时无权限限制）
test=> select oid, relname from sys_class where relname = 't1';
  oid  | relname
-------+---------
 16638 | t1
(1 行记录)
步骤 3：启用权限隔离并验证效果
-- 1. 切换回 system 用户，启用权限隔离
test=> \c -system
您现在以用户名"system"连接到数据库"test"

test=# alter database test enable object isolation;
ALTER DATABASE

-- 2. 再次切换为 u1，查询 t1（未授权，结果为空）
test=# \c -u1
您现在以用户名"u1"连接到数据库"test"

test=> select oid, relname from sys_class where relname = 't1';
 oid | relname
-----+---------
(0 行记录)
步骤 4：授予权限后重新验证
-- 1. system 用户授予 u1 表 t1 的 SELECT 权限
test=> \c -system
test=# grant SELECT on TABLE t1 to u1;
GRANT

-- 2. u1 再次查询，可正常看到 t1
test=# \c -u1
test=> select oid, relname from sys_class where relname = 't1';
  oid  | relname
-------+---------
 16638 | t1
(1 行记录)

3.2 进阶开发：新增隔离权限与对象

在我们实际应用的开发业务中经常自身需求自定义隔离权限（如DUMPTABLE）或新增隔离对象（如触发器 TRIGGER）等，对于这种情况ingbaseES 配套了完整且成熟的开发实现流程。
在这里插入图片描述

场景 1：新增隔离权限 DUMPTABLE

需求：为表对象新增 DUMPTABLE 权限，用户需获得该权限才能查看表并执行备份操作。

  1. 定位 RLS 策略：表对象对应的 RLS 为 sys_class_isolation_object_rls；
  2. 修改权限判断函数：更新 has_class_privilege_name_id 函数，将 DUMPTABLE 加入权限集合（参考前文函数代码）；
  3. 更新 RLS 策略：在 CreateRLSForSystemTableList 中添加 DUMPTABLE 权限：
// 为 sys_class 表的 RLS 策略添加 DUMPTABLE 权限
{RelationRelationId, "rel", "sys_class_isolation_object_rls", 
 "is_object_inclass", "security_utils", "currentuser", "oid", 
 "select,insert,update,delete,truncate,references,trigger,dumptable"}
  1. 验证效果：
-- system 授予 u1 表 t1 的 DUMPTABLE 权限
test=# grant DUMPTABLE on TABLE t1 to u1;
GRANT

-- u1 查询 t1，可正常显示
test=> \c -u1
test=> select oid, relname from sys_class where relname = 't1';
  oid  | relname
-------+---------
 16638 | t1
(1 行记录)
场景 2：新增隔离对象 TRIGGER

需求：将触发器纳入权限隔离范围，未授权用户无法查看触发器对象。

  1. 确定隔离对象映射：触发器对象对应系统表 _trigger；
  2. 定义权限判断函数：创建 has_trigger_privilege 函数，校验用户对触发器的权限：
Datum has_trigger_privilege(KDB_FUNCTION_ARGS) {
    Name username = KDB_GETARG_NAME(0);
    Oid trigid = KDB_GETARG_OID(1);
    text* priv_type_text = KDB_GETARG_TEXT_PP(2);
    
    Relation tgrel = table_open(TriggerRelationId, LockAccessShare);
    SysScanDesc tgscan;
    HeapTuple ht_trig;
    ScanKeyData skey[1];
    
    // 定位触发器对象
    ScanKeyInit(&skey[0], Anum__trigger_oid, BTEqualStrategyNumber, F_OIDEQ, ObjectIdGetDatum(trigid));
    tgscan = systable_beginscan(tgrel, TriggerOidIndexId, true, NULL, 1, skey);
    ht_trig = systable_getnext(tgscan);
    
    // 无对应触发器，返回无权限
    if (!HeapTupleIsValid(ht_trig)) {
        systable_endscan(tgscan);
        table_close(tgrel, LockAccessShare);
        KDB_RETURN_BOOL(false);
    }
    
    // 校验用户对触发器依赖表的权限（核心逻辑）
    Form__trigger trigrec = (Form__trigger)GETSTRUCT(ht_trig);
    if (!OidIsValid(trigrec->tgrelid) || !has_table_privilege(username, trigrec->tgrelid, "trigger")) {
        systable_endscan(tgscan);
        table_close(tgrel, LockAccessShare);
        KDB_RETURN_BOOL(false);
    }
    
    KDB_RETURN_BOOL(true);
}
  1. 新增 RLS 策略：在 CreateRLSForSystemTableList 中添加触发器对应的 RLS：
{TriggerRelationId, "trge", "sys_trigger_isolation_object_rls", 
 "has_trigger_privilege", "security_utils", "currentuser", "oid", "execute"}

四、功能限制与注意事项

  1. BYPASSRLS 属性绕过：若用户拥有 BYPASSRLS 属性，将直接跳过权限隔离检查，因此需严格控制该属性的授予，仅分配给数据库管理员；
  2. 数据库簇状态一致性：同一数据库簇下，所有数据库的权限隔离状态（启用/禁用）必须保持一致，不可部分启用、部分禁用；
  3. 权限兼容性：新增隔离权限时，需确保权限判断函数与 RLS 策略的权限集合一致，避免因权限不匹配导致的查询异常；
  4. 工具端适配：在 KStudio 等 KingbaseES 配套工具中，权限隔离效果会同步生效——未授权对象不会在“表”“触发器”等导航栏中显示，与 SQL 查询结果保持一致。

五、总结

KingbaseES 从兼容 MySQL 核心语法简化迁移流程，到突破突破基础兼容局限，以权限隔离筑牢数据安全防线。既降低了企业的迁移成本和技术门槛，也减少了因为切换数据库导致业务中断的风险。通过权限隔离对权限控制进行细粒化的控制，来为企业数据安全保驾护航，助力企业在数字化时代实现安全与发展的双赢。

# mysql # oracle # android
Logo
松山湖开发者村综合服务平台

助力广东及东莞地区开发者，代码托管、在线学习与竞赛、技术交流与分享、资源共享、职业发展，成为松山湖开发者首选的工作与学习平台

更多推荐

cover

DeepSeek源码解构：从MoE架构到MLA的工程化实现

avatar 松山湖开发者村综合服务平台
cover

【GitHub开源AI精选】OpenLens AI：清华推出的医学研究全自主AI助手，开启科研新纪元

avatar 松山湖开发者村综合服务平台
cover

【案例共创】基于华为开发者空间云开发环境（容器）开发构建AI

avatar 松山湖开发者村综合服务平台