你有没有遇到过这种情况GBase 8s里辛辛苦苦建好一个账号该授的权限也授了用户登录后却什么都查不了。问了一圈发现是会话里缺了一条SET ROLE。这种情况在缺省角色概念出现之前太常见了尤其当权限是通过角色下发的时候。后来我意识到问题不在用户记性差而在权限设计本身——你把权限放进了角色里却没有提供一个“让角色自动生效”的机制。GBase 8s里的缺省角色DEFAULT ROLE就是专门来解决这件事的。这篇文章不打算讲太虚的东西就围绕缺省角色说清楚几件事它解决什么痛点、背后的角色权限机制长什么样、怎么一步步定义、生效边界在哪里、实操中哪些坑我替你踩过。如果你正在管理GBase 8s的权限或者刚接手一个角色权限混乱的库这篇应该值得你花十分钟看完。1. 缺省角色到底解决了什么问题三个让人头疼的权限场景1.1 会话级角色激活用户永远记不住SET ROLE在GBase 8s里角色不会天然生效。你要先GRANT一个角色给用户用户登录之后还要执行SET ROLE角色里的权限才会真正落到会话上。问题就出在这个“还要执行”上。正常开发人员谁会记得他们只知道账号密码登录后直接SELECT。结果就是各种“为什么查不了”“昨天还可以今天怎么不行了”的工单。更麻烦的是跑批任务凌晨的JOB如果没在脚本里写SET ROLE报错日志里只会留下一句权限不足排查起来得翻半天。缺省角色解决的就是这个“默认生效”问题。你把它定义好用户登录的那一刻角色就自动激活了不需要用户在客户端做任何额外动作。一套配置所有派生出来的会话都受用。这个特性对降低日常权限工单量的帮助是立竿见影的。1.2 直接授权一时爽权限回收火葬场有一种偷懒做法很常见反正用户就几个人直接把表权限授给用户算了。我刚管库那会儿也这么干过。用户少还好用户一多授权关系就像蜘蛛网。更要命的是有人离职之后他的账号可能还挂着十几个表的权限没人敢删怕影响业务。角色机制能让这件事变得清爽。权限集中放在角色上用户只是角色的成员。离职了一条REVOKE把角色摘掉权限干干净净跟着走。而缺省角色在其中的作用是让这个“干净”的标准贯彻到登录环节——不用每次靠人肉提醒去SET ROLE权限的基准状态从一开始就是你设计好的那一套。1.3 多角色切换的日常繁琐有些账号不是“一个人”在用。比如一个应用账号白天给报表查询用途晚上要跑数据修正的批量任务。查询只需要只读角色批量任务需要读写角色。不肯切角色吧权限太大反而容易出事老老实实切吧每次都得先SET ROLE再干活。如果把这个账号的缺省角色设成使用频率最高的只读角色大部分时候登录即用。需要批量任务权限时再临时切到另一个角色用完切回来。日常操作省了一堆事权限结构也清晰多了。这个场景很多团队都遇到过只是没意识到缺省角色能顺手解决掉。2. 搞懂缺省角色之前先搞懂角色是怎么玩的2.1 一句话理解角色权限的集装箱角色是什么我习惯把它理解成“权限的集装箱”。你不需要一次一次往用户身上贴表权限、过程权限而是先把这些权限打包放进一个角色再把角色分配给用户。用生活里的事打比方一张门禁卡卡里面可以挂多个门禁权限组。你去哪间会议室取决于卡上被勾选了哪个权限组。用户-角色-权限三者就是这么个关系。缺省角色相当于门禁系统里默认勾选的那一组——你刷卡进门自动就是这个组的权限范围。2.2 角色相关的核心语句先梳理一下和角色、缺省角色相关的SQL方便后面串起来看。这张表建议存一下后面实操频繁会用到。操作SQL说明创建角色CREATE ROLE r_readonly定义一个新的角色容器给角色授对象权限GRANT SELECT ON tab TO r_readonly把权限装进角色把角色授予用户GRANT r_readonly TO zhangsan让用户拥有这个角色设置缺省角色ALTER USER zhangsan WITH DEFAULT ROLE r_readonly指定登录自动激活的角色会话内切换角色SET ROLE r_readonly手动激活某个角色恢复缺省角色SET ROLE DEFAULT回到默认状态注意GRANT在这张表里出现两次。一次是“授权给角色”一次是“把角色给人”两者作用是不同层面的。很多新手在这里犯迷糊GRANT r_readonly TO zhangsan这条语句发给库之后以为权限直接生效了结果用户一查表还是被拒绝——因为角色是给了但会话里的角色还没有激活。这个和2.3连起来看就明白了。2.3 登录瞬间发生了什么假设用户zhangsan拥有角色r_readonly并且这个角色被设成了缺省角色。当他用客户端登录GBase 8s时数据库在建立会话的过程中会做一件事把DEFAULT ROLE指定的那个角色自动激活到这个会话上。效果等同于数据库替你执行了一句SET ROLE r_readonly。用户从头到尾不需要知道自己有什么角色也不需要做任何操作登录之后SELECT权限就在了。这就是“缺省角色”最核心的机制。反过来如果用户拥有角色但缺省角色没有配置登录后这个角色是“休眠”的。除非手动执行SET ROLE否则角色里的权限一个都不会生效。这也是很多权限“看起来配了但用不了”的根本原因。3. 手把手定义缺省角色从零到一的全过程3.1 动手之前先确认版本支持DEFAULT ROLE不是一个很古老的功能属性。你在动手前先确认一下当前实例版本。可以用onstat工具或者管理客户端查看版本号也可以直接翻一下随版本发布的SQL指南。就我的经验较新的8.x系列版本都支持但具体哪个版本开始引入、语法细节是否略有调整必须以你手上这套环境的官方手册为准。另外执行这些操作的人需要有对应的权限。通常由DBA操作或者至少具备CREATE ROLE、GRANT、ALTER USER等语句的执行权限。建议先在测试实例上把流程走一遍确认无误再上生产。3.2 创建角色并装载权限先建一个角色。以只读分析角色为例CREATE ROLE r_readonly;然后往角色里装权限。给指定表授权GRANT SELECT ON TABLE t_orders TO r_readonly; GRANT SELECT ON TABLE t_customers TO r_readonly; GRANT SELECT ON TABLE t_products TO r_readonly;如果某个存储过程也需要允许执行一并挂到角色上GRANT EXECUTE ON PROCEDURE sp_daily_report TO r_readonly;这里的原则是权限尽量收进角色不要散落在用户级别。后面管理时只维护角色这一个入口就够了。如果需要调整某类人的访问范围改角色的权限集即可所有拥有这个角色的用户会同步受到影响。3.3 把角色授予用户并设置成缺省角色角色装好权限之后先把它授予目标用户GRANT r_readonly TO zhangsan;然后用ALTER USER把该角色指定为缺省角色ALTER USER zhangsan WITH DEFAULT ROLE r_readonly;如果是新建用户可以一步到位CREATE USER zhangsan IDENTIFIED BY Pssw0rd WITH DEFAULT ROLE r_readonly;顺序很重要先让用户拥有角色再设置缺省角色。如果角色还没有授予用户就去设置缺省角色数据库会直接报错或者拒绝处理。这点在第5章会单独展开讲。记住这个顺序先GRANT角色给用户再ALTER USER设置缺省角色。反过来大概率报错。3.4 验证缺省角色是否真的生效配置完成之后别急着交差做一次黑盒验证最靠谱。新开一个会话不执行任何SET ROLE语句直接查r_readonly角色权限下的那张表SELECT * FROM t_orders LIMIT 1;能查出数据说明登录时缺省角色自动激活了。如果报权限不足就按下面的链路排查确认角色确实已GRANT给该用户确认ALTER USER语句执行成功无报错确认你用的连接不是复用了一个很久之前建立的旧会话在新会话中执行SELECT测试而不是在老会话里测。4. 缺省角色不是“唯一角色”生效边界与权限叠加的规则4.1 一个用户可以有多个角色但缺省只有一个用户和角色是多对多关系。一个用户可以拥有r_readonly和r_write等多个角色但DEFAULT ROLE只能设定一个。也就是说登录时自动激活的只有那一个角色其他角色处于休眠需要手动SET ROLE切换才生效。这里要提醒一句在我接触过的GBase 8s版本里会话内同时激活的角色只有一个语义上是以最后一次SET ROLE为准。这一点和常见的关系型数据库产品不太一样设计权限时别默认“拥有即生效”一定区分“拥有”和“当前激活”两个状态。实际场景中用户卡在“我明明有这个角色为什么权限不对”的时候十有八九是当前激活的角色不是他以为的那个。用SET ROLE切一下或者直接用SET ROLE DEFAULT回到缺省角色问题通常就解决了。4.2 直接授权与角色授权权限取并集有一个细节容易被忽略用户直接收到的授权和通过当前激活角色拿到的授权是并集关系。场景当前激活角色权限用户直接权限最终生效权限操作A允许拒绝允许操作B拒绝允许允许操作C拒绝拒绝拒绝也就是说哪怕你把某个权限从角色里REVOKE掉只要该用户之前被直接授过这个权限他照样能访问。反过来也一样直接REVOKE用户的权限只要角色里还留着通过角色他依然能访问。所以做权限收敛的时候不能只改角色。你得同时检查“用户直接被授的权限”和“用户通过角色拿到的权限”两本账才算彻底。这是我踩过不少坑之后得出的结论尤其是接手老库的时候里面往往积压了大量历史直接授权。4.3 WITH GRANT OPTION默认角色可能带来的权限扩散如果授权给角色时带了WITH GRANT OPTION那么拥有这个角色且角色处于激活状态的用户可以把自己手上的权限再转授给其他人。举个例子角色r_query对某张核心表有SELECT权限并且是WITH GRANT OPTION授进来的。业务人员把角色设成缺省角色后他登录就有转授权限的能力。如果他没有安全意识顺手把权限转给了别人后续审计时你会发现授权链条变得很难追溯。我的建议核心、敏感对象的授权尤其涉及WITH GRANT OPTION时尽量不下放到角色更不要让带这种标记的角色成为缺省角色。缺省角色是高频默认态默认态里挂着转授权风险面会放大很多。5. 实战排查定义缺省角色时最容易踩的四个坑5.1 角色还没授予用户就急着设置缺省角色现象执行ALTER USER zhangsan WITH DEFAULT ROLE r_readonly时数据库提示类似“用户与角色之间的成员关系不存在”或者直接报错。这种情况最常见的原因就是GRANT r_readonly TO zhangsan根本没有执行或执行失败没注意。正确做法是严格按步骤来先GRANT角色再设置缺省角色。如果你在管理多个环境还要小心确认是在同一个实例上执行的。跨实例的授权和设置缺省角色根本就是两回事别这边设置完那边发现用户压根不在这个库上。5.2 改完缺省角色不生效先有会话过期还有手动角色覆盖这是生产环境里最像“灵异事件”的一个坑。DBA明明把缺省角色从r_readonly改成了r_write用户却反馈权限一点变化没有。第一个原因缺省角色是在会话建立时生效的。用户手里已经打开的连接仍然保留着旧会话的激活状态不会因为你改了设置就自动跟着变。如果是应用通过连接池复用老连接那就更典型了——连接池里每个连接的会话状态都可能是“历史遗留”。处理办法是让应用重连或者重启连接池让新会话去读取最新配置。第二个原因用户登录之后自己手动SET ROLE到别的角色了。这种覆盖是合法的数据库不会拦但你查半天查不到问题。验证方法很简单让用户执行SET ROLE DEFAULT再看权限状态是否恢复成你配置的预期。排查这类问题我的经验是先把“会话是否新建”和“当前激活的角色是谁”这两件事确认掉再去看配置有没有写对。顺序反了容易白忙活。实际排查顺序建议先确认会话是否新建再确认当前激活的角色最后才去复查配置。5.3 DROP ROLE之后的连锁反应有时候因为业务调整要把整个角色删掉。如果直接DROP ROLE可能出现两种情况一是角色仍有成员数据库拒绝删除二是强删之后用户这边还残留着对缺省角色的引用登录时出现异常。我的建议是删除角色前先做一次清理查清楚哪些用户拥有这个角色逐一REVOKE然后把用户里指向该角色的DEFAULT ROLE配置改掉或清掉最后再执行DROP ROLE。顺序做对删除才干净后续不会有用户登录时被“引用了一个不存在的角色”这种怪问题。5.4 导入导出脚本把缺省角色弄丢现在很多人会在不同环境之间同步用户和授权数据可能是GBase 8s自带的模式导出工具也可能是第三方同步脚本。这类工具导出对象权限、角色成员一般都能导出来但“缺省角色”这种偏配置性的属性往往是最容易在迁移过程中丢掉的。我遇到过的情况是测试库验证一切正常导出到生产库之后用户登录查表各种报错。查了一圈角色和GRANT都在就是DEFAULT ROLE没有跟着导过去。用户登录后角色根本没激活权限自然就是空的。处理办法不要在导入导出之后想当然认为“结构和权限一致”。每迁移一批用户单独核对一次DEFAULT ROLE设置必要时用ALTER USER补一遍。这个动作很便宜能帮你省掉后续大量排查工单。6. 让缺省角色成为权限治理的锚点几个长期好用的习惯6.1 按岗位建模而不是按人建模用得久了你会发现缺省角色最大的价值不是省事而是逼着你把权限设计变成“建角色-挂权限-配用户”的标准流程。我给团队定的规矩是先有角色后有用户用户默认都配一个缺省角色。角色按岗位或应用模块建模比如r_readonly只读分析r_business_write业务录入与修改r_batch批量处理r_dba管理维护。新员工入职创建用户、挂上对应角色、设置缺省角色三步走完。转岗或者离职REVOKE角色即可。不需要再经历“这个人到底有哪些表的权限”的考古式排查。6.2 审计时先看默认角色再看额外角色做权限审计时我会先拉一份“用户-缺省角色”清单。缺省角色决定了每个用户登录后的基准权限这一层必须干净。然后再看用户拥有的其他角色和直接授权确认是否存在过度授权。比较实用的检查项是否所有用户都设置了缺省角色是否存在长期不登录但拥有大量角色的账号是否有角色带WITH GRANT OPTION授给了过多用户是否有敏感表的权限直接授到了用户级别、绕过了角色。这些检查不一定需要复杂的脚本几条查询就能跑完。关键是坚持定期做而不是等到安全事件发生了才去翻。6.3 我坚持下来的三个操作习惯第一所有权限变更脚本都记录下来走版本管理不手工在命令行里敲。这样出了问题可以回看历史知道哪个时间点改了什么。第二每次变更先在测试实例上完整验证包括“新会话登录后权限是否符合预期”这一步。生产环境直接操作永远是最后手段。第三和业务方约定一个窗口做权限变更错开批量任务和报表高峰期。不然你正改着角色凌晨的任务报错锅还是你的。最后聊聊我的整体感受。把缺省角色用起来之后权限相关的工单数量明显降了一个台阶。最直接的变化是用户不再因为“忘记SET ROLE”这种问题来烦我权限的基准状态也从“靠人自觉”变成了“系统自动”。如果你目前的环境还是直接授权加手动切角色的模式建议抽个时间把高频账号梳理一遍先建角色、再挂权限、最后设缺省角色。改动过程中记住一个原则先小范围验证再推广到全库。另外再提醒一句不同版本的GBase 8s对DEFAULT ROLE的支持细节可能存在差异动手之前一定先翻你的版本手册。
GBase 8s缺省角色（DEFAULT ROLE）：让数据库权限自动生效的实战指南
你有没有遇到过这种情况GBase 8s里辛辛苦苦建好一个账号该授的权限也授了用户登录后却什么都查不了。问了一圈发现是会话里缺了一条SET ROLE。这种情况在缺省角色概念出现之前太常见了尤其当权限是通过角色下发的时候。后来我意识到问题不在用户记性差而在权限设计本身——你把权限放进了角色里却没有提供一个“让角色自动生效”的机制。GBase 8s里的缺省角色DEFAULT ROLE就是专门来解决这件事的。这篇文章不打算讲太虚的东西就围绕缺省角色说清楚几件事它解决什么痛点、背后的角色权限机制长什么样、怎么一步步定义、生效边界在哪里、实操中哪些坑我替你踩过。如果你正在管理GBase 8s的权限或者刚接手一个角色权限混乱的库这篇应该值得你花十分钟看完。1. 缺省角色到底解决了什么问题三个让人头疼的权限场景1.1 会话级角色激活用户永远记不住SET ROLE在GBase 8s里角色不会天然生效。你要先GRANT一个角色给用户用户登录之后还要执行SET ROLE角色里的权限才会真正落到会话上。问题就出在这个“还要执行”上。正常开发人员谁会记得他们只知道账号密码登录后直接SELECT。结果就是各种“为什么查不了”“昨天还可以今天怎么不行了”的工单。更麻烦的是跑批任务凌晨的JOB如果没在脚本里写SET ROLE报错日志里只会留下一句权限不足排查起来得翻半天。缺省角色解决的就是这个“默认生效”问题。你把它定义好用户登录的那一刻角色就自动激活了不需要用户在客户端做任何额外动作。一套配置所有派生出来的会话都受用。这个特性对降低日常权限工单量的帮助是立竿见影的。1.2 直接授权一时爽权限回收火葬场有一种偷懒做法很常见反正用户就几个人直接把表权限授给用户算了。我刚管库那会儿也这么干过。用户少还好用户一多授权关系就像蜘蛛网。更要命的是有人离职之后他的账号可能还挂着十几个表的权限没人敢删怕影响业务。角色机制能让这件事变得清爽。权限集中放在角色上用户只是角色的成员。离职了一条REVOKE把角色摘掉权限干干净净跟着走。而缺省角色在其中的作用是让这个“干净”的标准贯彻到登录环节——不用每次靠人肉提醒去SET ROLE权限的基准状态从一开始就是你设计好的那一套。1.3 多角色切换的日常繁琐有些账号不是“一个人”在用。比如一个应用账号白天给报表查询用途晚上要跑数据修正的批量任务。查询只需要只读角色批量任务需要读写角色。不肯切角色吧权限太大反而容易出事老老实实切吧每次都得先SET ROLE再干活。如果把这个账号的缺省角色设成使用频率最高的只读角色大部分时候登录即用。需要批量任务权限时再临时切到另一个角色用完切回来。日常操作省了一堆事权限结构也清晰多了。这个场景很多团队都遇到过只是没意识到缺省角色能顺手解决掉。2. 搞懂缺省角色之前先搞懂角色是怎么玩的2.1 一句话理解角色权限的集装箱角色是什么我习惯把它理解成“权限的集装箱”。你不需要一次一次往用户身上贴表权限、过程权限而是先把这些权限打包放进一个角色再把角色分配给用户。用生活里的事打比方一张门禁卡卡里面可以挂多个门禁权限组。你去哪间会议室取决于卡上被勾选了哪个权限组。用户-角色-权限三者就是这么个关系。缺省角色相当于门禁系统里默认勾选的那一组——你刷卡进门自动就是这个组的权限范围。2.2 角色相关的核心语句先梳理一下和角色、缺省角色相关的SQL方便后面串起来看。这张表建议存一下后面实操频繁会用到。操作SQL说明创建角色CREATE ROLE r_readonly定义一个新的角色容器给角色授对象权限GRANT SELECT ON tab TO r_readonly把权限装进角色把角色授予用户GRANT r_readonly TO zhangsan让用户拥有这个角色设置缺省角色ALTER USER zhangsan WITH DEFAULT ROLE r_readonly指定登录自动激活的角色会话内切换角色SET ROLE r_readonly手动激活某个角色恢复缺省角色SET ROLE DEFAULT回到默认状态注意GRANT在这张表里出现两次。一次是“授权给角色”一次是“把角色给人”两者作用是不同层面的。很多新手在这里犯迷糊GRANT r_readonly TO zhangsan这条语句发给库之后以为权限直接生效了结果用户一查表还是被拒绝——因为角色是给了但会话里的角色还没有激活。这个和2.3连起来看就明白了。2.3 登录瞬间发生了什么假设用户zhangsan拥有角色r_readonly并且这个角色被设成了缺省角色。当他用客户端登录GBase 8s时数据库在建立会话的过程中会做一件事把DEFAULT ROLE指定的那个角色自动激活到这个会话上。效果等同于数据库替你执行了一句SET ROLE r_readonly。用户从头到尾不需要知道自己有什么角色也不需要做任何操作登录之后SELECT权限就在了。这就是“缺省角色”最核心的机制。反过来如果用户拥有角色但缺省角色没有配置登录后这个角色是“休眠”的。除非手动执行SET ROLE否则角色里的权限一个都不会生效。这也是很多权限“看起来配了但用不了”的根本原因。3. 手把手定义缺省角色从零到一的全过程3.1 动手之前先确认版本支持DEFAULT ROLE不是一个很古老的功能属性。你在动手前先确认一下当前实例版本。可以用onstat工具或者管理客户端查看版本号也可以直接翻一下随版本发布的SQL指南。就我的经验较新的8.x系列版本都支持但具体哪个版本开始引入、语法细节是否略有调整必须以你手上这套环境的官方手册为准。另外执行这些操作的人需要有对应的权限。通常由DBA操作或者至少具备CREATE ROLE、GRANT、ALTER USER等语句的执行权限。建议先在测试实例上把流程走一遍确认无误再上生产。3.2 创建角色并装载权限先建一个角色。以只读分析角色为例CREATE ROLE r_readonly;然后往角色里装权限。给指定表授权GRANT SELECT ON TABLE t_orders TO r_readonly; GRANT SELECT ON TABLE t_customers TO r_readonly; GRANT SELECT ON TABLE t_products TO r_readonly;如果某个存储过程也需要允许执行一并挂到角色上GRANT EXECUTE ON PROCEDURE sp_daily_report TO r_readonly;这里的原则是权限尽量收进角色不要散落在用户级别。后面管理时只维护角色这一个入口就够了。如果需要调整某类人的访问范围改角色的权限集即可所有拥有这个角色的用户会同步受到影响。3.3 把角色授予用户并设置成缺省角色角色装好权限之后先把它授予目标用户GRANT r_readonly TO zhangsan;然后用ALTER USER把该角色指定为缺省角色ALTER USER zhangsan WITH DEFAULT ROLE r_readonly;如果是新建用户可以一步到位CREATE USER zhangsan IDENTIFIED BY Pssw0rd WITH DEFAULT ROLE r_readonly;顺序很重要先让用户拥有角色再设置缺省角色。如果角色还没有授予用户就去设置缺省角色数据库会直接报错或者拒绝处理。这点在第5章会单独展开讲。记住这个顺序先GRANT角色给用户再ALTER USER设置缺省角色。反过来大概率报错。3.4 验证缺省角色是否真的生效配置完成之后别急着交差做一次黑盒验证最靠谱。新开一个会话不执行任何SET ROLE语句直接查r_readonly角色权限下的那张表SELECT * FROM t_orders LIMIT 1;能查出数据说明登录时缺省角色自动激活了。如果报权限不足就按下面的链路排查确认角色确实已GRANT给该用户确认ALTER USER语句执行成功无报错确认你用的连接不是复用了一个很久之前建立的旧会话在新会话中执行SELECT测试而不是在老会话里测。4. 缺省角色不是“唯一角色”生效边界与权限叠加的规则4.1 一个用户可以有多个角色但缺省只有一个用户和角色是多对多关系。一个用户可以拥有r_readonly和r_write等多个角色但DEFAULT ROLE只能设定一个。也就是说登录时自动激活的只有那一个角色其他角色处于休眠需要手动SET ROLE切换才生效。这里要提醒一句在我接触过的GBase 8s版本里会话内同时激活的角色只有一个语义上是以最后一次SET ROLE为准。这一点和常见的关系型数据库产品不太一样设计权限时别默认“拥有即生效”一定区分“拥有”和“当前激活”两个状态。实际场景中用户卡在“我明明有这个角色为什么权限不对”的时候十有八九是当前激活的角色不是他以为的那个。用SET ROLE切一下或者直接用SET ROLE DEFAULT回到缺省角色问题通常就解决了。4.2 直接授权与角色授权权限取并集有一个细节容易被忽略用户直接收到的授权和通过当前激活角色拿到的授权是并集关系。场景当前激活角色权限用户直接权限最终生效权限操作A允许拒绝允许操作B拒绝允许允许操作C拒绝拒绝拒绝也就是说哪怕你把某个权限从角色里REVOKE掉只要该用户之前被直接授过这个权限他照样能访问。反过来也一样直接REVOKE用户的权限只要角色里还留着通过角色他依然能访问。所以做权限收敛的时候不能只改角色。你得同时检查“用户直接被授的权限”和“用户通过角色拿到的权限”两本账才算彻底。这是我踩过不少坑之后得出的结论尤其是接手老库的时候里面往往积压了大量历史直接授权。4.3 WITH GRANT OPTION默认角色可能带来的权限扩散如果授权给角色时带了WITH GRANT OPTION那么拥有这个角色且角色处于激活状态的用户可以把自己手上的权限再转授给其他人。举个例子角色r_query对某张核心表有SELECT权限并且是WITH GRANT OPTION授进来的。业务人员把角色设成缺省角色后他登录就有转授权限的能力。如果他没有安全意识顺手把权限转给了别人后续审计时你会发现授权链条变得很难追溯。我的建议核心、敏感对象的授权尤其涉及WITH GRANT OPTION时尽量不下放到角色更不要让带这种标记的角色成为缺省角色。缺省角色是高频默认态默认态里挂着转授权风险面会放大很多。5. 实战排查定义缺省角色时最容易踩的四个坑5.1 角色还没授予用户就急着设置缺省角色现象执行ALTER USER zhangsan WITH DEFAULT ROLE r_readonly时数据库提示类似“用户与角色之间的成员关系不存在”或者直接报错。这种情况最常见的原因就是GRANT r_readonly TO zhangsan根本没有执行或执行失败没注意。正确做法是严格按步骤来先GRANT角色再设置缺省角色。如果你在管理多个环境还要小心确认是在同一个实例上执行的。跨实例的授权和设置缺省角色根本就是两回事别这边设置完那边发现用户压根不在这个库上。5.2 改完缺省角色不生效先有会话过期还有手动角色覆盖这是生产环境里最像“灵异事件”的一个坑。DBA明明把缺省角色从r_readonly改成了r_write用户却反馈权限一点变化没有。第一个原因缺省角色是在会话建立时生效的。用户手里已经打开的连接仍然保留着旧会话的激活状态不会因为你改了设置就自动跟着变。如果是应用通过连接池复用老连接那就更典型了——连接池里每个连接的会话状态都可能是“历史遗留”。处理办法是让应用重连或者重启连接池让新会话去读取最新配置。第二个原因用户登录之后自己手动SET ROLE到别的角色了。这种覆盖是合法的数据库不会拦但你查半天查不到问题。验证方法很简单让用户执行SET ROLE DEFAULT再看权限状态是否恢复成你配置的预期。排查这类问题我的经验是先把“会话是否新建”和“当前激活的角色是谁”这两件事确认掉再去看配置有没有写对。顺序反了容易白忙活。实际排查顺序建议先确认会话是否新建再确认当前激活的角色最后才去复查配置。5.3 DROP ROLE之后的连锁反应有时候因为业务调整要把整个角色删掉。如果直接DROP ROLE可能出现两种情况一是角色仍有成员数据库拒绝删除二是强删之后用户这边还残留着对缺省角色的引用登录时出现异常。我的建议是删除角色前先做一次清理查清楚哪些用户拥有这个角色逐一REVOKE然后把用户里指向该角色的DEFAULT ROLE配置改掉或清掉最后再执行DROP ROLE。顺序做对删除才干净后续不会有用户登录时被“引用了一个不存在的角色”这种怪问题。5.4 导入导出脚本把缺省角色弄丢现在很多人会在不同环境之间同步用户和授权数据可能是GBase 8s自带的模式导出工具也可能是第三方同步脚本。这类工具导出对象权限、角色成员一般都能导出来但“缺省角色”这种偏配置性的属性往往是最容易在迁移过程中丢掉的。我遇到过的情况是测试库验证一切正常导出到生产库之后用户登录查表各种报错。查了一圈角色和GRANT都在就是DEFAULT ROLE没有跟着导过去。用户登录后角色根本没激活权限自然就是空的。处理办法不要在导入导出之后想当然认为“结构和权限一致”。每迁移一批用户单独核对一次DEFAULT ROLE设置必要时用ALTER USER补一遍。这个动作很便宜能帮你省掉后续大量排查工单。6. 让缺省角色成为权限治理的锚点几个长期好用的习惯6.1 按岗位建模而不是按人建模用得久了你会发现缺省角色最大的价值不是省事而是逼着你把权限设计变成“建角色-挂权限-配用户”的标准流程。我给团队定的规矩是先有角色后有用户用户默认都配一个缺省角色。角色按岗位或应用模块建模比如r_readonly只读分析r_business_write业务录入与修改r_batch批量处理r_dba管理维护。新员工入职创建用户、挂上对应角色、设置缺省角色三步走完。转岗或者离职REVOKE角色即可。不需要再经历“这个人到底有哪些表的权限”的考古式排查。6.2 审计时先看默认角色再看额外角色做权限审计时我会先拉一份“用户-缺省角色”清单。缺省角色决定了每个用户登录后的基准权限这一层必须干净。然后再看用户拥有的其他角色和直接授权确认是否存在过度授权。比较实用的检查项是否所有用户都设置了缺省角色是否存在长期不登录但拥有大量角色的账号是否有角色带WITH GRANT OPTION授给了过多用户是否有敏感表的权限直接授到了用户级别、绕过了角色。这些检查不一定需要复杂的脚本几条查询就能跑完。关键是坚持定期做而不是等到安全事件发生了才去翻。6.3 我坚持下来的三个操作习惯第一所有权限变更脚本都记录下来走版本管理不手工在命令行里敲。这样出了问题可以回看历史知道哪个时间点改了什么。第二每次变更先在测试实例上完整验证包括“新会话登录后权限是否符合预期”这一步。生产环境直接操作永远是最后手段。第三和业务方约定一个窗口做权限变更错开批量任务和报表高峰期。不然你正改着角色凌晨的任务报错锅还是你的。最后聊聊我的整体感受。把缺省角色用起来之后权限相关的工单数量明显降了一个台阶。最直接的变化是用户不再因为“忘记SET ROLE”这种问题来烦我权限的基准状态也从“靠人自觉”变成了“系统自动”。如果你目前的环境还是直接授权加手动切角色的模式建议抽个时间把高频账号梳理一遍先建角色、再挂权限、最后设缺省角色。改动过程中记住一个原则先小范围验证再推广到全库。另外再提醒一句不同版本的GBase 8s对DEFAULT ROLE的支持细节可能存在差异动手之前一定先翻你的版本手册。
