TiDB 动态权限Dynamic Privileges设计解析从SUPER粗粒度授权走向精细化权限治理【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb本文围绕 TiDB 动态权限设计文档 展开结合 pkg/privilege 下的真实实现系统讲解 TiDB 动态权限的动机、表结构设计、权限检查 API、插件注册机制、元数据命令改动、初始权限清单与测试策略。读完本文你将理解动态权限与 SQL Role 的关系、GRANT/REVOKE对动态权限的语义约束以及如何在插件中注册自定义动态权限实现对 TiDB 更细粒度的访问控制。动态权限Dynamic Privileges是 TiDB 面向精细化授权场景的核心机制它允许插件按需注册命名权限如BACKUP_ADMIN、ROLE_ADMIN从而摆脱对粗粒度SUPER权限的依赖。本设计文档由 morgo 于 2021 年提出计划与 Security Enhanced Mode安全增强模式配合实现两者之间没有相互依赖关系。本文以该提案为主线并结合当前仓库中的落地代码还原其设计原貌与实现细节。背景与动机为什么 TiDB 需要动态权限MySQL 8.0 引入了动态权限概念WorkLog WL#8131。其设计意图是插件可以根据自身需要创建新的命名权限例如 Firewall Admin、Audit Admin而不必再依赖已经严重超载且过于粗粒度的SUPER权限。TiDB 同样存在对细粒度权限的需求因此采纳了与 MySQL 类似的实现思路。提案同时强调一个易混淆点动态权限与 SQL 角色RBAC不是一回事但两者可以协同工作。文档给出了一个完整的测试用例同时验证了动态权限、角色、SUPER兼容语义三者之间的关系mustExec(c, rootSe, CREATE USER notsuper) mustExec(c, rootSe, CREATE USER otheruser) mustExec(c, rootSe, CREATE ROLE anyrolename) mustExec(c, rootSe, SET tidb_enable_dynamic_privileges1) se : newSession(c, s.store, s.dbName) c.Assert(se.Auth(auth.UserIdentity{Username: notsuper, Hostname: %}, nil, nil), IsTrue) mustExec(c, se, SET tidb_enable_dynamic_privileges1) // test SYSTEM_VARIABLES_ADMIN _, err : se.ExecuteInternal(context.Background(), SET GLOBAL wait_timeout 86400) c.Assert(err.Error(), Equals, [planner:1227]Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation) mustExec(c, rootSe, GRANT SYSTEM_VARIABLES_admin ON *.* TO notsuper) mustExec(c, se, SET GLOBAL wait_timeout 86400) // test ROLE_ADMIN _, err se.ExecuteInternal(context.Background(), GRANT anyrolename TO otheruser) c.Assert(err.Error(), Equals, [planner:1227]Access denied; you need (at least one of) the SUPER or ROLE_ADMIN privilege(s) for this operation) mustExec(c, rootSe, GRANT ROLE_ADMIN ON *.* TO notsuper) mustExec(c, se, GRANT anyrolename TO otheruser) // revoke SYSTEM_VARIABLES_ADMIN, confirm it is dropped mustExec(c, rootSe, REVOKE SYSTEM_VARIABLES_AdmIn ON *.* FROM notsuper) _, err se.ExecuteInternal(context.Background(), SET GLOBAL wait_timeout 86000) c.Assert(err.Error(), Equals, [planner:1227]Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation) // grant super, confirm that it is also a substitute for SYSTEM_VARIABLES_ADMIN mustExec(c, rootSe, GRANT SUPER ON *.* TO notsuper) mustExec(c, se, SET GLOBAL wait_timeout 86400) // revoke SUPER, assign SYSTEM_VARIABLES_ADMIN to anyrolename. // confirm that a dynamic privilege can be inherited from a role. mustExec(c, rootSe, REVOKE SUPER ON *.* FROM notsuper) mustExec(c, rootSe, GRANT SYSTEM_VARIABLES_AdmIn ON *.* TO anyrolename) mustExec(c, rootSe, GRANT anyrolename TO notsuper) // Its not a default role, this should initially fail: _, err se.ExecuteInternal(context.Background(), SET GLOBAL wait_timeout 86400) c.Assert(err.Error(), Equals, [planner:1227]Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation) mustExec(c, se, SET ROLE anyrolename) mustExec(c, se, SET GLOBAL wait_timeout 87000)这个用例浓缩了动态权限的核心语义权限名大小写不敏感SUPER可作为 MySQL 兼容动态权限的替身动态权限可以被授予角色后再被用户继承此时受默认角色机制约束需SET ROLE激活。动态权限与静态权限的差异提案明确了动态权限区别于静态权限的四个关键点维度动态权限权限来源权限类型为DYNAMIC由插件注册产生服务器事先并不知道该权限的存在作用域只能全局作用域global scope存储位置存放在mysql.global_grants表而非mysql.user表GRANT OPTION按单个动态权限独立记录GRANT OPTION而非对用户整体详细设计持久化复用 MySQL 的mysql.global_grants表TiDB 直接复用了与 MySQL 相同的表结构来持久化动态权限CREATE TABLE global_grants ( USER char(32) NOT NULL DEFAULT , HOST char(255) NOT NULL DEFAULT , PRIV char(32) NOT NULL DEFAULT , WITH_GRANT_OPTION enum(N,Y) NOT NULL DEFAULT N, PRIMARY KEY (USER,HOST,PRIV) );设计文档特别说明TiDB 原本已存在一张mysql.global_priv表用于存储 TLS 选项等乍看功能相似但它有两个本质差异——PRIV列期望是 JSON 编码字符串且没有WITH_GRANT_OPTION列。由于该表中PRIV值是数据而非键强行复用会很混乱因此选择与 MySQL 保持同一套 schema。落地后的真实建表语句可以在 pkg/meta/metadef/system_tables_def.go 中找到实际实现只比提案多了一个KEY i_user (USER)辅助索引列结构完全一致CREATE TABLE IF NOT EXISTS mysql.global_grants ( USER char(32) NOT NULL DEFAULT , HOST char(255) NOT NULL DEFAULT , PRIV char(32) NOT NULL DEFAULT , WITH_GRANT_OPTION enum(N,Y) NOT NULL DEFAULT N, PRIMARY KEY (USER,HOST,PRIV), KEY i_user (USER) );该表在系统 bootstrap 阶段即被创建并纳入系统表 ID 管理见 pkg/session/bootstrap.go。与 MySQL 类似动态权限表在读取时会被整体载入内存缓存缓存结构与既有静态权限的缓存方式一致。在 pkg/privilege/privileges/cache.go 中可以看到查询语句sqlLoadGlobalGrantsTable SELECT HIGH_PRIORITY Host,User,Priv,With_Grant_Option FROM mysql.global_grantscache.go内存记录结构dynamicPrivRecord包含PrivilegeName与GrantOption两个字段见 cache.go缓存使用 B-Treep.dynamicPriv按用户索引LoadGlobalGrantsTable负责全量加载并做去重合并见 cache.go。权限检查 API动态权限需要独立的检查入口常规的静态权限检查通过RequestVerification完成它要求mysql.PrivilegeType是预定义好的枚举并且需要传入可能为空的库名、表名、列名三个参数。这对动态权限并不适用原因有三mysql.ProcessPriv这类权限必须预定义而动态权限是运行期才被插件注册的动态权限永远是全局的那三个空字符串参数永远不适用动态权限可以被单独授予GRANT OPTION某些场景如输出SHOW GRANTS需要区分拥有该权限与拥有该权限且可转授。为此提案设计了新的检查函数// RequestDynamicVerification(activeRole []*auth.RoleIdentity, priv string, grantable bool) bool if pm.RequestDynamicVerification(activeRoles, BACKUP_ADMIN, false) { // has backup admin privilege }当前仓库中该 API 已写入privilege.Manager接口pkg/privilege/privilege.go接口层面提供了三个方法HasExplicitlyGrantedDynamicPrivilege(activeRoles, privName, grantable)仅检查是否被显式授予RequestDynamicVerification(activeRoles, privName, grantable)常规检查含SUPER兼容回落RequestDynamicVerificationWithUser(ctx, privName, grantable, user)针对指定用户身份的检查。而 cache.go 中MySQLPrivilege的具体实现则采用了更完整的签名RequestDynamicVerification(activeRoles, user, host, privName, withGrant)其核心逻辑分为三层先调用HasExplicitlyGrantedDynamicPrivilege在用户自身 其所有激活角色列表上逐条匹配dynamicPriv缓存记录若要求withGrant则必须命中GrantOption见 cache.go如果启用了 Security Enhanced Mode且目标权限属于受限动态权限sem.IsRestrictedPrivilege(privName)则不再回落到 SUPER 判定直接返回 false——这正是RESTRICTED_*系列权限能真正隔离SUPER的底层保障出于向后兼容若请求withGrant则先校验GRANT权限再以SUPER作为动态权限的替身完成最终判定。实现注释明确指出未来若要以动态权限全面替代SUPER需要通过 bootstrap 任务为所有持有SUPER的用户补发动态权限否则BACKUP、ROLE_ADMIN等操作会开始失败见 cache.go。插件 API通过 OnInit 注册新的动态权限动态权限的价值在于可扩展因此框架需要为插件提供注册入口。提案给出的形式是插件在OnInit方法中直接调用import ( github.com/pingcap/tidb/privilege/privileges ) err privileges.RegisterDynamicPrivilege(AUDIT_ADMIN) if err ! nil { return err }在实现中pkg/privilege/privileges/privileges.go 提供了RegisterDynamicPrivilege与GetDynamicPrivileges两个导出函数注册时会将权限名统一转为大写并做重复检查然后追加到全局的dynamicPrivs切片查询时则返回一份拷贝避免调用方污染内部状态。此外privileges.go 的init()会将自身RegisterDynamicPrivilege挂载到extension.RegisterDynamicPrivilege钩子上使扩展体系见 pkg/extension/manifest.go也能以统一方式注册动态权限。元数据命令的语义变化引入动态权限后若干元数据命令的输出与语法需要随之调整。SHOW GRANTSSHOW GRANTS需要在静态权限之后逐一展示用户拥有的动态权限包括其GRANT OPTIONmysql [localhost:8023] {root} (test) show grants for u1; --------------------------------------------------------- | Grants for u1% | --------------------------------------------------------- | GRANT USAGE ON *.* TO u1% | | GRANT BINLOG_ADMIN ON *.* TO u1% | | GRANT BACKUP_ADMIN ON *.* TO u1% WITH GRANT OPTION | --------------------------------------------------------- 3 rows in set (0.00 sec)对应实现中SHOW GRANTS的构造逻辑会先合并用户及其激活角色继承来的全部动态权限来源角色可能同时授予同一动态权限需要做 grantable 取并集的合并再排序输出为GRANT priv1,priv2 ON *.* TO ...语句见 cache.go。Information_schema.user_privilegesuser_privileges视图应展示静态权限与动态权限的混合结果mysql [localhost:8023] {root} (information_schema) where grantee u1%; ------------------------------------------------------- | GRANTEE | TABLE_CATALOG | PRIVILEGE_TYPE | IS_GRANTABLE | ------------------------------------------------------- | u1% | def | USAGE | NO | | u1% | def | BINLOG_ADMIN | NO | | u1% | def | BACKUP_ADMIN | YES | ------------------------------------------------------- 3 rows in set (0.00 sec)实现中对应cache.go内遍历dynamicPriv缓存并追加记录到结果集的逻辑见 cache.go。SHOW CREATE USER / CREATE USER / ALTER USER这三个命令无需改动。GRANT / REVOKEGRANT/REVOKE需要同时支持静态权限与动态权限两种语法。动态权限只允许全局级*.*授予到更细粒度时应当报错mysql [localhost:8023] {root} (information_schema) grant select on *.* to u1; Query OK, 0 rows affected (0.00 sec) mysql [localhost:8023] {root} (information_schema) grant binlog_admin on test.* to u1; ERROR 3619 (HY000): Illegal privilege level specified for BINLOG_ADMIN mysql [localhost:8023] {root} (information_schema) grant binlog_admin on *.* to u1; Query OK, 0 rows affected (0.00 sec)GRANT ALL还会展开为在命令执行时刻服务器上已注册的全部动态权限。SHOW GRANTS会看到一行以SUPER为首的静态权限一行逗号分隔的全部动态权限以及单独一行带WITH GRANT OPTION的权限mysql [localhost:8023] {root} (test) show grants for u1; ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Grants for u1% | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO u1% | | GRANT APPLICATION_PASSWORD_ADMIN,AUDIT_ADMIN,BINLOG_ADMIN,BINLOG_ENCRYPTION_ADMIN,CLONE_ADMIN,CONNECTION_ADMIN,ENCRYPTION_KEY_ADMIN,FLUSH_OPTIMIZER_COSTS,FLUSH_STATUS,FLUSH_TABLES,FLUSH_USER_RESOURCES,GROUP_REPLICATION_ADMIN,INNODB_REDO_LOG_ARCHIVE,INNODB_REDO_LOG_ENABLE,PERSIST_RO_VARIABLES_ADMIN,REPLICATION_APPLIER,REPLICATION_SLAVE_ADMIN,RESOURCE_GROUP_ADMIN,RESOURCE_GROUP_USER,ROLE_ADMIN,SERVICE_CONNECTION_ADMIN,SESSION_VARIABLES_ADMIN,SET_USER_ID,SHOW_ROUTINE,SYSTEM_USER,SYSTEM_VARIABLES_ADMIN,TABLE_ENCRYPTION_ADMIN,XA_RECOVER_ADMIN ON *.* TO u1% | | GRANT BACKUP_ADMIN ON *.* TO u1% WITH GRANT OPTION | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 3 rows in set (0.00 sec)需要说明的是设计提案保留了 TiDB 现状SHOW GRANTS读回时不展开GRANT ALL的静态权限部分仅把动态权限作为独立行输出。这一行为差异可以保持不变。GRANT/REVOKE的实现位于 pkg/executor/grant.go 与 pkg/executor/revoke.go。初始动态权限集提案将首批动态权限划分为两类从 MySQL 借用的权限以及 TiDB 专有的扩展权限。从 MySQL 借用权限名描述备注BACKUP_ADMIN允许执行 BR 备份/恢复以及 lightning 恢复。此前需要SUPER今后需要BACKUP_ADMIN或SUPER。SYSTEM_VARIABLES_ADMIN允许修改任意 GLOBAL 系统变量。此前需要SUPER今后需要SYSTEM_VARIABLES_ADMIN或SUPER。ROLE_ADMIN允许授予和回收角色。不允许对 restricted_users 执行回收见下文。CONNECTION_ADMIN允许 kill 连接。类似静态权限PROCESS但更严格不允许 show processlist。SYSTEM_USER仅拥有CREATE USER权限的用户不能修改或删除该用户。有助于防止权限提升。TiDB 扩展权限名描述备注RESTORE_ADMIN恢复操作比备份风险更高应要求更多权限。灵感来自 MySQL 的BACKUP_ADMIN/CLONE_ADMIN但 MySQL 无在线恢复故不适用。RESTRICTED_VARIABLES_ADMIN允许修改受限的 GLOBAL 系统变量。当前 SEM 下所有高风险变量被卸载。未来可能要求只有持此权限者而非SUPER可见/可设置这些变量。RESTRICTED_STATUS_ADMIN允许观测受限的状态变量。例如启用 SEM 时SHOW GLOBAL STATUS默认隐藏部分统计信息。RESTRICTED_CONNECTION_ADMIN允许 kill 属于其他用户的连接。详见下表描述。RESTRICTED_USER_ADMIN特殊权限持有者的访问权限不能被SUPER用户改变。面向 DBaaS 的 CloudAdmin 用户设计。RESTRICTED_TABLES_ADMIN豁免 SEM 隐藏表语义的特殊权限。面向 DBaaS 的 CloudAdmin 用户设计。关于 kill 连接的完整权限矩阵kill 自己用户的连接总是允许kill 其他用户连接需要CONNECTION_ADMIN或SUPER但对于RESTRICTED_USER_ADMIN用户有例外——要 kill 这些连接还需要RESTRICTED_CONNECTION_ADMIN。该语义同时作用于KILL与KILL TIDB命令。随着仓库演进内置动态权限列表已远不止上述内容。当前 privileges.go 中的dynamicPrivs初始集合还包含var dynamicPrivs []string{ BACKUP_ADMIN, RESTORE_ADMIN, SYSTEM_USER, SYSTEM_VARIABLES_ADMIN, ROLE_ADMIN, CONNECTION_ADMIN, PLACEMENT_ADMIN, // Can Create/Drop/Alter PLACEMENT POLICY DASHBOARD_CLIENT, // Can login to the TiDB-Dashboard. RESTRICTED_TABLES_ADMIN, // Can see system tables when SEM is enabled RESTRICTED_STATUS_ADMIN, // Can see all status vars when SEM is enabled. RESTRICTED_VARIABLES_ADMIN, // Can see all variables when SEM is enabled RESTRICTED_USER_ADMIN, // User can not have their access revoked by SUPER users. RESTRICTED_CONNECTION_ADMIN, // Can not be killed by PROCESS/CONNECTION_ADMIN privilege RESTRICTED_REPLICA_WRITER_ADMIN, // Can write to the sever even when tidb_restriced_read_only is turned on. RESTRICTED_PRIV_ADMIN, // Can grant the restricted priv to others RESTRICTED_SQL_ADMIN, // Can execute restricted SQL statements RESOURCE_GROUP_ADMIN, // Create/Drop/Alter RESOURCE GROUP RESOURCE_GROUP_USER, // Can change the resource group of current session. TRAFFIC_CAPTURE_ADMIN, // Can capture traffic TRAFFIC_REPLAY_ADMIN, // Can replay traffic APPLICATION_PASSWORD_ADMIN, // Self-service RETAIN CURRENT PASSWORD / DISCARD OLD PASSWORD; cross-user retain/discard requires CREATE USER. }可以看到后续围绕资源组RESOURCE_GROUP_*、流量回放TRAFFIC_*、放置策略PLACEMENT_ADMIN、DashboardDASHBOARD_CLIENT以及读写限制RESTRICTED_REPLICA_WRITER_ADMIN等逐渐衍生出更多细粒度权限这也印证了动态权限应随功能演进持续扩展的设计初衷。Parser 层面的变更TiDB parser 当时已经支持DYNAMIC权限在 GRANT 语句解析中它们以静态类型ExtendedPriv被送出。提案用一个调试补丁验证了这一点——在 planner/core/planbuilder.go 的collectVisitInfoFromGrantStmt中临时打印item.Namemysql grant acdc on *.* to u1; ERROR 8121 (HY000): privilege check fail ### Attempting to set DYNAMIC privilege: acdc这说明 GRANT 解析已能识别出动态权限名只是权限检查阶段会拒绝一个服务器未注册的权限。提案同时指出仍需检查ExtendedPriv是否在所有上下文例如 REVOKE都被支持。一个值得注意的边界语义创建与动态权限同名的角色是被允许的。GRANT语句通过是否带ON *.*来区分二者GRANT BINLOG_ADMIN TO u1; // 授予名为 binlog_admin 的角色 GRANT BINLOG_ADMIN ON *.* TO u1; // 授予 binlog_admin 这个动态权限这个细微差别与 MySQL 行为一致。文档计划元数据命令SHOW GRANTS、user_privileges等的语句参考页需要补充动态权限说明同时需要专门的DYNAMIC权限文档说明其工作方式与细粒度访问控制的目的。测试设计动态权限测试的复杂之处在于权限有多种继承路径既可以直接 GRANT 给用户也可以授予用户继承的角色。功能测试Functional Tests单测覆盖角色/动态权限之间的优先级语义包括以不同顺序逻辑恢复restore的情况单测逐一覆盖初始动态权限集同时验证直接授予与通过角色RBAC授予两条路径集成测试需要覆盖 global kill 开启/关闭两种场景。对应的测试代码可以在 pkg/privilege/privileges/privileges_test.go 及 cache_test.go 中找到。场景测试Scenario TestsDBaaS 团队结合security-enhanced-mode设计见 2021-03-09-security-enhanced-mode.md需要验证的典型场景矩阵如下Account NamerootcloudAdminBackup Restore to cloudYYFile privilegeNNRead or set variablesYYset restricted variables部分甚至不可读NYRead or set restricted system tablesNYDROP USER cloudAdminN很难为 N除非硬编码REVOKE cloudAdminN很难为 N除非硬编码Show processlist、访问属于其他用户的线程YYSUPER 用户忘记密码时修改其密码NYKill 属于 cloudAdmin 的连接NYSHUTDOWN / RESTARTNY在 k8s 上对 tidb-server 优雅关机场景测试需要覆盖全部动态权限以及若干用户自定义的动态权限。兼容性测试Compatibility Tests引入DYNAMIC权限预计不会带来兼容性问题因为向后兼容有保障SUPER仍可替代 MySQL 兼容动态权限。但插件应当迁移到注册自己的动态权限而非继续依赖SUPER——这被视为一项增强不在动态权限初始引入先为插件搭好框架的范围内。影响与风险实验性开关动态权限在首次发布时受实验性功能开关tidb_enable_dynamic_privileges控制可在 GLOBAL 或 SESSION 粒度设置。实现方式是限制GRANT/REVOKE语句创建动态权限条件性地修改 AST visitor 功能过于侵入。向后兼容为兼容 MySQL动态权限同时允许SUPER生效。这有助于避免升级问题——例如 TiDB bootstrap 时执行过GRANT ALL ON *.*的用户并不会因此获得全部动态权限。如果未来改为用BACKUP_ADMIN替代SUPER升级/降级流程可能受到影响但首个版本计划两者皆可。备选方案与未决问题如何为低权限用户追加动态权限一个典型的运营场景cloudAdmin不持有SUPER但未来某天需要被授予新增的细粒度权限。提案列举了五种潜在方案编写session/bootstrap.go的 bootstrap 任务把已有的某个DYNAMIC权限拆分成两个——即持有XYZ的用户现在同时拥有XYZ与ZYX授予cloudAdminSELECT, INSERT, UPDATE ON mysql.*与RELOAD ON *.*使其能直接向global_grants表插入ZYX并执行FLUSH PRIVILEGES刷新权限缓存为注册新动态权限的插件增加 API使其在首次安装时可声明ZYX也可由XYZ满足触发一次内部权限复制支持类似 MySQL--init-file的功能以不受限权限执行启动脚本将权限管理器完全插件化它当前是一个接口扩展到插件并不困难把 cloudAdmin 权限嵌入到云专属的权限管理器中不依赖内部系统表。提案给出的推荐做法是方案 (1)方案 (2) 并不能有效约束cloudAdmin的凭据(3) 只是绕过了visitInfo不支持权限 OR 条件的现状(4) 与 (5) 有价值但需要超出本提案范围的额外开发投入。小结动态权限为 TiDB 提供了一套命名权限可按需注册、全局作用域、按权限独立记录可转授标志、存于mysql.global_grants表并缓存于内存的细粒度授权框架。它与 SQL Role 正交、与SUPER向后兼容、与 Security Enhanced Mode 协同生效为备份恢复、系统变量管理、连接治理、DBaaS 云管账号等高风险操作提供了更精确的最小权限表达。对于希望阅读第一手设计的读者原始提案位于 docs/design/2021-03-09-dynamic-privileges.md接口定义见 pkg/privilege/privilege.go核心实现集中在 pkg/privilege/privileges/cache.go 与 pkg/privilege/privileges/privileges.go。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考