【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1.8
【问题描述】漏洞扫描到OB v4.2.1.8存在普通用户越权调用存储过程的问题，即普通用户可通过调用其他用户的存储过程，对无权限表进行增删改查操作。
已确认obv4.2.5版本新增execute权限，限制普通用户的存储过程执行权限。通过OCP平台升级到v4.2.5.7后，验证原有租户依旧可以执行，尝试新建租户则限制生效
请问这是什么原因？只能通过新建租户，迁移数据的方式来升级吗？
已确认obv4.2.5版本新增execute权限，限制普通用户的存储过程执行权限。通过OCP平台升级到v4.2.5.7后，验证原有租户依旧可以执行，尝试新建租户则限制生效
请问这是什么原因？只能通过新建租户，迁移数据的方式来升级吗？
12 个赞
还有这情况，不应该吧
2 个赞
22%%++
225588996633
8866900741%%%%%%%
用心了
1 个赞
是不是要对原有租户，回收execute权限。
1 个赞
查询权限表是没有execute权限的，也手动revoke了，还是能执行
排查有发现mysql.procs_priv视图的信息没有同步更新，而该视图数据来源是oceanbase.__all_routine_privilege表
__all_routine_privilege表和__all_routine表数据不一致
这个可以手动upgrade吗？
1 个赞
升级不会改变老租户的行为，新建租户会收紧的权限。
这种情况手动把权限收回
3 个赞
漏洞原理
1）OceanBase 4.2.1 版本不会对MySQL 模式的PL对象权限做检查，因此没有做权限控制。
2）从4.2.2 版本以后，新增指定MySQL 的PL对象权限检查是否生效的变量 _enable_mysql_pl_priv_check ,1表示开启，0表示关闭。对于租户的变量值这里分2种情况：
a) 如果租户是从4.2.1版本升级到4.2.2及以上版本，_enable_mysql_pl_priv_check=0，则需要手动设置变量来打开该权限控制功能（即_enable_mysql_pl_priv_check置为1），并手动将相关权限grant。
b) 如果租户是在4.2.2及以上版本新建，_enable_mysql_pl_priv_check=1 ， 不需要额外处理 。
3）受影响的对象：PROCEDURE ,FUNCTION 和TRIGGER的相关权限。
3 个赞
可以试一试，是不是这个参数有影响哈
2 个赞
基本上了，除非是新问题， 已知的这个漏洞是我提交过的，所以印象深刻~
2 个赞
OceanBase 版本升级后，新增功能对原有租户不生效而对新建租户生效，通常是因为部分新特性依赖租户级别的元数据初始化或参数默认值变更，旧租户保留了升级前的配置状态，需手动触发同步或调整参数。
核心原因：
1.参数默认值未自动继承：新版本引入的新配置项，旧租户的 GV$OB_PARAMETERS中可能仍显示为旧默认值或未显式设置，而新租户创建时直接应用了新版本的默认值。
2.元数据初始化差异：部分功能（如新索引类型、优化器行为、安全策略）在租户创建时初始化元数据结构，旧租户缺乏对应的元数据标记，导致功能不可用。
3.升级模式未完全收尾：若集群升级后未执行完整的 upgrade_post 脚本或租户级升级任务（UPGRADE_ALL），部分租户级特性可能未激活。
赞一个！
可能处于安全的考虑吧
牛掰。。。。。。。
厉害
