设计文档 on Kernel Notes

海量 1 设计 oracle加密函数

Tue, 25 Feb 2025 09:49:00 +0800

1

设置默认版本

contrib/pgcrypto/pgcrypto.control

defaultl_version = '2.0'
dbcompatibilities = 'A, B, PG'

生成同名的sql文件

touch contrib/pgcrypto/pgcrypto-2.0.sql

安装sql文件

# pgcrypto.control与pgcrypt.*.sql文件
ll $GAUSSHOME/share/postgresql/extension | grep pgcrypto

加载插件

# 执行：CREATE EXTENSION pgcrypto
 ..
 CreateExtension
 check_valild_extension_name # 检查插件名：要求不含 '-'、不含'..'等路径字符
 get_extension_oid
 heap_open('pg_extension')
 systable_beginscan # 遍历系统表 pg_extension：确保插件存在
 read_extension_control_file
 parse_extension_control_file
 get_extension_control_filename
 sprintf("{share}/extension/{extension_name}.control")
 ParreConfigFp
 # 获取 directory, default_version, module_pathname, dbcompatibilities 等参数
 get_extension_script_filename
 get_extension_script_direcotry
 if name is 'pgcrypto':
 sprintf("{script_dir}/crypto-a.sql")
 read_extension_script_file
 InsertExtensionTuple # 插入系统表 pg_extension
 execute_extension_script
 ApplyExtensionUpdates

海量 2 设计 profile

Thu, 06 Mar 2025 11:32:00 +0800

1 Oracle兼容性-支持profile功能

1.1 功能简述

本特性实现与oracle profile相同的功能，支持为不同用户设置7个不同的配置参数：

failed_login_attempts
password_lock_time
password_life_time
password_grace_time
password_reuse_time
password_reuse_max
idle_time

简单使用示例如下：

CREATE PROFILE pro1 LIMIT failed_login_attempts 10;
CREATE USER u1 PASSWORD 'u1.pass1';
ALTER USER u1 PROFILE u1;

1.2 实现方案

一、元数据

本特性的关键实现为：对用户提供DDL接口，在内核中存储配置数据。因此，在介绍代码流程前，先介绍接口与元数据。

新增GUC参数resource_limit (与oracle参数名一致)
控制是否启用oracle profile功能。
如果该参数为on，以下5个guc参数则不再生效：[failed_login_attempts, password_lock_time, password_effect_time, password_reuse_time, password_reuse_max]。另外，对于已经过身份认证的连接，session_timeout也不再生效，相关功能均由profile中的用户级参数控制。
对于新安装的集群、旧版本升级的集群，该参数的值存在差异：
- 新安装：新安装的数据库，即3.0.8版本及之后，该guc参数值默认为on（初始值为off，由initdb自动设置为on）
- 升级：从3.0.8之前版本，升级到3.0.8版本时，在升级的过程中，该参数的值仍然是off，即升级上来默认不可用profile功能
```
SELECT * FROM pg_settings WHERE name = 'resource_limit';

 -[ RECORD 1 ]-------------------------------------------
 name | resource_limit
 setting | on -- 默认为on （由initdb设置为on，从旧版本升级到新版本时，升级脚本会将该参数设置为off）
 unit |
 category | Ungrouped
 short_desc | Used to enable profile feature
 extra_desc | default on
 context | postmaster -- 需重启生效
 vartype | bool
 source | default
 min_val |
 max_val |
 enumvals |
 boot_val | off
 reset_val | off
 sourcefile |
 sourceline |
```
修改6个GUC参数的生效条件
当GUC参数resource_limit取值为on时，以下6个GUC参数不再生效：[failed_login_attempts, password_lock_time, password_effect_time, password_reuse_time, password_reuse_max, session_timeout]

海量 2 设计 oracle profile

Thu, 20 Feb 2025 19:24:00 +0800

2

代码
新增试图

SELECT * FROM pg_user_settings;
-- 新增视图 pg_user_settings

SELECT rolname,profile FROM pg_authid WHERE rolcanlogin = true
 LEFT JOIN vb_profile ON

rolname | setname | setting | settype | settype | setsource
--------+-----------------------+----------+---------+-------------+----------------
 u1 | password_effect_time | 90 | int | profile guc | pro1
 | cluster guc | postgresql.conf

参数1: failed_login_attempts

# opegauss使用1个内存中的hash表，存储密码失败次数
ClientAuthentication
 # 进行身份认证时，如果认证失败，则更新hash表中的失败次数值
 UpdateFailCountToHashTable
 InitAccountLockHashTable
 hash_search
 # 如果失败次数超过GUC限制，则锁定账户
 if failed_login_attempts：
 lockflag = True

参数2: password_lock_time

参数3: password_effect_time

# 通过内置函数，主动查看密码剩余天数
gs_password_deadline
 GetCurrentUserId # 1 获取当前用户
 GetUserCurrentPwdtime # 2 从系统表pg_auth_history中，获取密码创建时间passwordtime
 heap_open('pg_auth_history')
 systable_beginscan
 floor(u_sess->attr.attr_security.Password_effect_time) # 3 从guc参数password_effect_time中获取密码有效天数
 # 计算步骤2和3中的时间，返回剩余过期天数

参数4: password_reuse_max

AddAuthHistory
 systable_beginscan('pg_auth_history') # 1 从系统表pg_auth_history中，获取曾用过的密码rolpassword，获取生成密码的时间passwordtime
 systable_getnext_back # 倒着从系统表扫描，即先扫描不太古老的旧密码，再扫描更古老的旧密码

 pg_sha256_encrypt # 使用旧密码的salt，加密新密码
 if strncmp : # 比较新密码是否与旧密码相等
 hasSame = True

 # 如果新旧密码相等，计算新旧密码间隔天数，与GUC参数password_reuse_time比较，判断是否满足密码重用时间限制
 if now - pg_auth_history.passwordtime > 'password_reuse_time'：
 isTimeSafe = True

 # 计算这是倒数第几个密码
 changeTimes++
 if changeTimes > 'password_reuse_max':
 isMaxSafe

 # 满足 password_reuse_time 和 password_reuse_max 中任意一个条件，都可以修改密码
 # - 要么用好几次之前的密码（满足 password_reuse_max 条件）
 # - 要么用很旧之间使用的密码（满足 password_reuse_time 条件）
 if hasSame and not isTimeSafe and not isMaxSafe:
 # 报错

参数5: password_reuse_time

海量 5 设计 G100审计

Mon, 01 Sep 2025 18:00:00 +0800

G100审计功能重构

1 功能简述

在需求文档中，已详细介绍需求背景，此处不在重复介绍。
G100 309之前版本，审计特性存在较多问题，因此，在本版本，将重新设计与实现审计特性，解决功能、性能、易用性、可维护性、可扩展性等问题，使审计特性达到大规模商用的标准。

2 实现方案

一、审计架构

审计特性，核心子功能如下：

配置审计：通过GUC参数，配置审计参数：日志目录、目录大小、日志文件淘汰策略等
设置范围：通过SQL语法，设置审计策略，控制哪些事件需审计。在策略中，可按用户、操作、对象、操作结果等过滤事件
收集事件：在代码关键节点，收集事件
过滤事件：根据审计策略，过滤无需审计的事件
生成日志：提取事件关键信息，生成日志
传输日志：工作线程，通过共享内存，传输日志给审计线程
存储日志：审计线程，组织日志，并将其存储至文件中。文件存放在单独的日志目录
查询日志：通过内置FUNCTION，在线查询日志，通过TOOL，离线查询日志

其中，设置范围、过滤事件子功能相对独立，可单独设计与实现，所以，拆分到另一个的设计文档中。

审计特性整体架构图如下：

二、工作流程

收集事件的主体、操作、客体等信息时，因为需收集操作结果，即操作成功或失败，所以，很多场景中，收集事件需分为2个阶段：

执行操作前：收集事件基本信息，包括操作类型等
执行操作后：收集事件的操作结果。对于出现ERROR的场景，则在异常处理函数中收集操作结果。

在所有事件中，DML语句的事件稍复杂一点，此处主要以该类语句为例，梳理整体执行流程：

三、详细流程

阶段1 配置审计（进程启动）

首先，用户通过GUC参数，配置审计文件管理等功能。然后，在系统启动阶段，审计模块将根据配置，初始化的各类关键资源，包括：

日志文件：日志存储目录，初始日志文件等
审计内存：日志缓存区，内存上下文等
审计线程：信号处理函数等
事件收集节点：hook函数注册等

详细启动过程如下：

main # 1. 启动vastbase进程
 knl_instance_init
 MemoryContextInit
 PostmasterMain # 2. 启动postmaster线程
 SelectConfigFiles # 3. 加载GUC参数
 checkDataDir
 'audit_dir_init' # 4. 创建审计日志文件目录
 'audit_hook_init' # 5. 注册审计回调函数：身份认证等
 load_hba
 reset_shared
 CreateSharedMemoryAndSemaphores # （日志缓冲区不是共享内存，后文阶段6详细介绍）
 GlobalSysDBCache::Init
 CreateLocalSysDBCache
 InitRoleIdHashTable
 'audit_comm_init' # 6. 初始化审计内存上下文、日志缓存区，创建审计日志文件
 'initialize_util_thread(AUDIT_WRITER)' # 7. 启动audit-writer 线程，持续读取日志缓冲区，等待接收与存储日志
 initialize_thread
 ..
 # ===== audit-writer 线程 ==============
 GaussDbThreadMain
 InitShmemAccess
 InitAuxiliaryProcess
 CreateSharedMemoryAndSemaphores
 GaussDBAuxiliaryThreadMain
 BaseInit
 'adt_writer_main'
 # ===== audit-writer 线程 ==============
 ServerLoop
 for (;;)
 comm_select
 ConnCreate # 9. 接收客户端连接
 BackendStartup
 initialize_util_thread(WORKER)
 initialize_thread
 ..
 # ===== postgres 线程 ==============
 GaussDbThreadMain
 knl_thread_init
 InitializeGUCOptions
 CreateLocalSysDBCache
 'audit_hook_init' # 10. 注册事件收集回调函数：计划执行、函数执行等回调点
 BackendInitialize
 BackendRun
 PostgresMain
 # ===== postgres 线程 ==============
 'initialize_util_thread(AUDIT_WRITER)' # 11. 检查audit-writer 线程状态与自动重启

阶段2 设置范围

向用户提供SQL接口，用于创建审计策略。（见另一个设计文档）

海量 5 方案 G100审计重构

Wed, 23 Apr 2025 18:00:00 +0800

1 审计特性介绍
2 使用审计特性
3 审计特性变更点
3 审计特性详细设计
4 审计后续重构计划

摘要

介绍审计特性，分析性能问题，提出优化方案，评审优化方案，规划其他计划

1 审计特性介绍

1.1 核心功能

审计特性：记录数据库内的各种事件，事件包括：

海量 6 设计 greenplum

Thu, 15 May 2025 16:36:00 +0800

1 需求分析

透明加密
- 主密钥
动态脱敏
- 和统一审计共用resource lable模块
全密态
- 密态等值
- 密态非等值
  - 范围查询：OPE保序加密
  - 模糊查询
  - 内置函数
  - 排序
  - ..
防篡改
- 分布式：有点麻烦，区块链记录在每个节点上
- 哈希函数：md5

1.1 透明加密

模块分析
- 密钥管理
  - 设置主密钥
- 定义加密属性
  - 表：普通表、临时表、分区表、toast表
  - 索引
  - xlog
- 加密数据
  - 加密算法：aes-256-ctr, sm4-ctr
  - 备机加密

-- 创建主密钥

-- 设置表加密
CREATE TABLE t1 (c1 INT, c2 TEXT) WITH (enable_tde=on);

-- 验证数据加密存储
INSERT INTO t1 VALUES (1, 'bbbcccddd');

1.2 动态脱敏

-- 开启脱敏功能
gs_guc reload -D $GAUSSHOME/data -c "enable_security_policy=on"

-- 创建表
CREATE TABLE t1 (c1 TEXT, c2 TEXT);
INSERT INTO t1 VALUES ('bbccdd', 'bbccdd');

-- 创建用户
CREATE USER u1 PASSWORD 'u1.password';
CREATE USER u2 PASSWORD 'u2.password';
GRANT SELECT ON t1 TO u1;
GRANT SELECT ON t1 TO u2;

-- 创建资源标签（只对u1脱敏）
CREATE RESOURCE LABEL l1 ADD COLUMN(t1.c1);
CREATE MASKING POLICY m1 randommasking ON LABEL(l1) FILTER ON ROLES(u1);

-- 验证脱敏：只有u1脱敏
SET ROLE u1 PASSWORD 'u1.password';
SELECT * FROM t1;
RESET ROLE;

SET ROLE u2 PASSWORD 'u2.password';
SELECT * FROM t1;
RESET ROLE;

-- 清理环境
DROP MASKING POLICY m1;
DROP RESOURCE LABEL l1;
DROP TABLE t1;
DROP USER u1,u2;

1.3 全密态

模块分析
- 客户端
  - 语法解析
  - 语义分析
  - 加密
- 服务端
  - ..

1.4 防篡改

hash算法：md5

2 greenplum

yum install zstd libzstd-devel krb5-devel krb5-libs cyrus-sasl-gssapi libevent-devel libyaml-devel libxml2 libxml2-devel curl libcurl-devel
yum install apr apr-devel apr-util apr-util-devel
yum install expat-devel openldap-devel bzip2 bzip2-devel xerces-c xerces-c-devel python36-devel

ln -s /usr/include/python2.7/Python.h /usr/include/Python.h

# 报错就降级
yum downgrade expat-2.1.0-12.el7

mkdir install
cd install
# echo ''使用单引号可防止变量$PATH等展开
echo '
export GPHOME=`pwd`/install

export BINARYLIBS=`pwd`/../third
export GCC_PATH=$BINARYLIBS/buildtools/gcc10.3
export CC=$GCC_PATH/gcc/bin/gcc
export CXX=$GCC_PATH/gcc/bin/g++
export LD_LIBRARY_PATH=$GCC_PATH/gcc/lib64:$GCC_PATH/isl/lib:$GCC_PATH/mpc/lib/:$GCC_PATH/mpfr/lib/:$GCC_PATH/gmp/lib/:$LD_LIBRARY_PATH
export PATH=$GCC_PATH/gcc/bin:$PATH
' > genv
# 建议把环境变量再在~/.bashrc中写一份，因为初始化集群时，需要ssh登录，以初始化segment节点

./configure --with-python --with-libxml --with-gssapi --without-zlib --with-gpcc --prefix=$GPHOME
make -sj 16
make install -sj 16

echo "
ARRAY_NAME="Greenplum Cluster"
SEG_PREFIX=gpseg #segment数据库前缀名
PORT_BASE=40000 #segment数据库起始端口号
declare -a DATA_DIRECTORY=(//home/shenkun/gp/install/segdata)
#segments数据目录，有几个DATA_DIRECTORY, 每个节点上便会启动几个segment，本例为2个segment
MASTER_HOSTNAME=master #master主机名
MASTER_DIRECTORY=/home/shenkun/gp/install/master #master数据目录
MASTER_PORT=5000 #master端口号，也是对外业务端口号
TRUSTED_SHELL=ssh
CHECK_POINT_SEGMENTS=8
ENCODING=UNICODE
DATABASE_NAME=gpdb
MACHINE_LIST_FILE=/home/shenkun/gp/install/hostfile #集群配置文件，hostfile对应7中创建的文件名
" > gpcfg

echo "master" > hostfile

gpinitsystem -c gpcfg -a

psql -p 5000 -d gpdb

PGOPTIONS='-c gp_session_role=utility' psql -p 40000 -d gpdb

# @ master
exec_simple_query
 pg_parse_query
 pg_analyze_and_rewrite
 pg_plan_queries
 pg_plan_querie
 planner
 standard_planner
 subquery_planner
 cdbllize_adjust_top_path
 create_plan
 cdbpathtoplan_create_flow
 makeFlow
 cdbllize_decorate_subplans_with_motions
 PortalStart
 ExecutorStart
 standard_ExecutorStart
 CdbDispatchPlan
 # @ segment
 exec_mpp_query
 deserializeNode
 PortalStart
 PortalRun
 PortalDrop
 PortalRun
 PortalRunMulti
 ProcessQuery
 ExecutorStart
 ExecutorRun
 standard_ExecutorRun
 ExecutePlan
 ExecutorFinish
 ExecutorEnd
 PortalDrop

WAL 加密模块设计

Mon, 07 Sep 2026 15:30:00 +0800

假设集群里已经存在表级透明加密模块，在此基础上设计一个高性能、高易用性的 WAL 加密模块。

WAL 加密的难点几乎不在"加密"本身，而在两件事：同一个 8KB 页会被反复重写，以及恢复路径要在拿不到 catalog 的时候就能解密。下面按设计决策的顺序展开。

1 威胁模型

先划清边界，因为它直接决定后面几个取舍。

要防的：磁盘 / 备份 / 归档介质被拖走；DBA 之外的运维人员直接读 pg_wal/；WAL 归档到对象存储。
不防的：有 root 权限的在线攻击者（内存里必然有明文）、旁路攻击。

1.1 为什么不用 dm-crypt 了事

如果只是防"介质丢失"，块设备加密（LUKS/dm-crypt）性价比高得多。在数据库内核里做 WAL 加密，真正的理由只有三个：

密钥要由数据库自己管，不能落在 OS 层（密评 / 国测要求）；
归档件要天然带密；
和已有的表级 TDE 共用一套密钥体系。

设计要始终对齐这三个理由，否则很容易做成一个又慢、又没多大意义的模块。

1.2 FPI 是必须堵的洞

既然表级 TDE 已经存在，那么 FPI（full page image）就是个必堵的泄漏点。

如果 TDE 是在 smgr 层做的（缓冲区里是明文、写盘时加密），那么 WAL 里的 FPI 记录的是明文页 —— 加密表的数据会原封不动地漏进 WAL。

只要集群里存在任何一张加密表，WAL 加密就必须强制开启，不能是两个独立开关。

实现上做成一个集群级的 data_encryption = on，或者至少让 CREATE ENCRYPTION POLICY 在 WAL 加密未开启时直接报错。这是易用性设计里最重要的一条：不要把一个"配错了就静默泄密"的组合留给用户。

海量 9 设计 E100审计

Tue, 22 Jul 2025 14:28:00 +0800

1 E100审计功能

1.1 功能简述

【审计功能】
审计是重要的安全特性，核心功能是收集数据库内的事件，例如：登录用户、创建对象、查询数据等，根据事件生成与审计日志，存储审计日志，向用户提供日志查询接口。使用方式请看需求文档。

【审计架构】
审计整体架构如下图所示：（“线程“替换为“进程”，原图不小心弄丢了，不好修改了，将就看）

【审计流程】

1.2 实现方案

一、启动审计进程

1. 启动postmaster进程 # PostmasterMain
 2. 加载GUC参数 # SelectConfigFiles
 2.1 '---加载审计GUC---'
 3. 创建共享内存和信号量 # reset_shared -> CreateSharedMemoryAndSemaphores
 3.1 计算共享内存总大小
 '计算审计共享内存大小：根据GUC配置'
 3.2 创建共享内存 # PGSharedMemoryCreate
 3.3 创建LwLock # CreateLWLocks
 3.4 初始化wal-buffer共享内存 # XLOGShmemInit
 3.5 初始化share-buffer共享内存 # InitBufferPool
 3.6 '如果开启审计：初始化审计共享内存：划分共享内存，包括audit-buffer'
 4. 启动sys-log进程 # SysLogger_Start
 5. '如果开启审计：初始化审计模块'
 5.1 '日志目录：检验与创建审计日志目录'
 5.2 '日志文件：每次重启，使用新的日志文件，方便用户单个删除日志文件'
 5.3 '内存上下文：创建审计全局内存上下文'
 5.4 '审计缓存区：初始化audit-buffer'
 5.5 '审计文件：初始化审计文件（并发write, read, delete日志）'
 5.6 '回调函数：在执行DDL、计划、函数等关键函数中，注册生成审计事件、日志的回调函数' # 后面详细介绍
 6. '如果开启审计：启动审计进程'
 6.1 '信号：注册信号处理函数：sighup, sigquit, sigusr1'
 6.2 '显示：设置ps命令显示的进程信息'
 6.3 主循环
 6.4 '等待事件：关键是timeout'
 6.5 '存储日志：读取audit-buffer中待落盘的日志，并存储' # 后面详细介绍
 6.6 '调整速率：按照每次落盘数据的长度，动态调整timeout'
 连续多次为0，timeout依次变为1ms, 100ms, 1s
 单次落盘长度大于16m，timeout=0
 7. '主循环' # ServerLoop
 7.1 接收客户端连接 # select
 7.2 创建postgres进程 # BackendStartup -> BackendRun -> PostgresMain
 7.3 检查与重启sys-log进程 # SysLogger_Start
 7.4 '检查与重启审计进程'
 7.5 检查与重启checkpointer进程 # StartCheckpointer
 7.6 检查与重启wal-writer进程 # StartWalWriter

二、收集审计事件

目前，只有以下2类进程，会生成审计事件：

分享编写需求/设计文档的个人经验

Tue, 15 Jul 2025 10:54:00 +0800

1 简介

1.1 分享的主题

分享一些编写需求、设计文档经验

1.2 分享的背景

背景：我写的需求文档，（相对）还算详细，所以有此次分享
- 308.1，profile功能的需求文档：https://www.tapd.cn/60475194/markdown_wikis/show/#1160475194001007196
根因：前公司流程繁重，被迫养成这种习惯。
分享的内容：可分享的干货不多，我觉得，在写文档的过程中，大部分人想的很详细，只是没有编写到文档中，毕竟每个人都有自己的编写风格。所以，本文的重点，是介绍前公司流程与要求，并以我做过的需求为例，为大家提供一点参考。
分享人经历：交过10+个不算小的需求，完整写过10+次需求与设计文档，格式与海量的接近。
分享的局限：交付的需求，主要是安全方向，也涉及SQL、存储等多个模块，所以，本文主要以安全需求的角度写，其他模块的需求不一定适用。

1.3 前公司的流程

与海量相比，前公司的交付流程，几乎一样：

客户：提出需求
产品、项目、测试、架构等：审核需求
开发：撰写需求/设计文档
各角色：评审需求/设计文档
开发：编写代码
…

其中，在4.评审需求/设计文档环节，前公司区别较大：

一、评审人员多

编号	角色	评审人	目的
1	开发	安全组、SQL组、存储组、运维组、..	避免影响其他模块，协助发现风险
2	测试	测试人、测试组长	学习新需求，识别测试重点
3	架构	架构设计	避免影响其他模块，确保后向兼容
4	资料	资料优化、资料审核	学习新需求
5	用例	用例审核	确保各种check可看护功能
6	其他	流程提升	-

二、评审通过难
1. 组内评审
2. 线上评审：上述所有角色会上评审，不过，一般很多人会议冲突，关键靠线下评审
3. 线下评审（关键流程）：各类角色共10+必选评审人，通过在线需求文档、设计文档了解需求，提出疑问，提出意见。开发分析解决后，找提出人确认意见，才算闭环。最后，所有必选评审人评审通过，才算完成流程。

在这种流程中，需求与设计文档，要满足很多要求：

普适：考虑到其他组开发、测试、资料等角色，不熟悉本领域的基础知识，所以，需要详细介绍相关原理，很多原理需要从头介绍
完整：要充分例举所有可能涉及风险，否则，评审人会认为未考虑到

举例：做了1个需求，可以为表设置加密属性，需要考虑：系统表、用户表（atore表、ustore表、分区表、临时表、toast表、unlogged表、segment表、hashbuckent表、物化视图…）

2 需求文档写作思路

2.1 分析过程

首先，客户提出需求，很多需求不够清晰。

示例：

profile原始需求：

目前对于数据库用户的管理方式不够便捷，无法像Oracle为用户赋予一组安全策略。一些属性如密码有效期、密码过期天数、密码尝试次数等也只能全局设定，无法指定用户配置。

然后，以我的个人习惯，分析需求的流程如下：

海量 10 设计 SSL协议

Tue, 09 Sep 2025 18:48:00 +0800

1 TLS协议支持第三方流量审计

1.1 功能简述

【需求背景】
TLS协议，是保障通信安全的加密协议，可分为4个子功能：

密钥生成：通过密钥交换或密钥协商等协议，让双方生成相同的密钥
身份认证：在开始阶段，双方均向对方发送自己的证书。双方接收证书后，基于PKI体系，校验证书是否合法。
数据加密：发送方发生数据前，使用密钥加密数据，发送数据密文。接受方接受密文后，使用密钥解密，获取数据。
数据校验：在加密数据的同时，生成数据完整性校验码，与数据密文拼接在一起。（简单理解：生成数据的哈希值，并使用密钥加密哈希值）接收方解密数据后，同样生成数据完整性校验码，与接收的相比，判断是否一致。

开源软件libssl.so提供TLS功能，应用只需调用接口，即可实现TLS协议。同时，libssl.so提供100+算法套件，可让应用选择不同的参数组合，1个算法套件，包含4个关键参数：

密钥生成：密钥生成协议
身份认证：证书算法类型
数据加密：加密算法类型
数据校验：哈希算法类型

例如，libssl.so中，常用的算法套件为：ECDHE-RSA-AES128-SHA256，该套件中，参数的含义如下：

密钥生成协议：ECDHE协议。（常见协议类型:DHE、ECDHE、RSA等）
证书算法类型：RSA
加密算法类型：AES-128
哈希算法类型：SHA-256

【需求分析】
vastbase支持TLS协议，当vsql与vastbase通信时，双方可使用TLS模块，生成密钥，并使用密钥加密、解密通信数据，包括：SQL语句、SQL执行结果等。
客户可能采用第三方工具，截取网络流量，获取传输中的SQL等数据，进行流量审计。但是，在使用TLS协议的情况下，网络中的数据是密文形式，无法进行流量审计。

vastbase提供1个GUC参数ssl_ciphers，用于配置TLS协议采用的算法套件，旧版本，该参数的取值范围如下：

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-SM4-CBC-SM3
4个仅tassl支持的国密算法套件

上述7个套件中，密钥生成协议为：ECDHE、DHE，此类DH协议，无法让第三方工具获取密钥。

本版本，新增4个算法套件：

AES128-SHA256
AES256-SHA256
AES128-GCM-SHA256
AES256-GCM-SHA384

上述4个套件，密钥生成协议为：RSA，该协议可让第三方工具获取密钥，使其可解密网络流量，获取SQL语句、SQL执行结果等。

【需求实现】
之前，vastbase限制ssl_ciphers的取值范围，仅放开7个算法套件，本版本，将新增放开4个算法套件。

实现时，仅修改ssl_ciphers的取值范围，新增支持4个算法套件[AES128-SHA256、AES256-SHA256、AES128-GCM-SHA256、AES256-GCM-SHA384]，4个算法套件将直接传递给libssl.so，内核不做任何处理。

因此，本需求无复杂设计。本文主要介绍完整的TLS协议工作原理。

1.2 实现方案

一、ECDHE与RSA的区别

此处简化ECDHE与RSA的步骤与算法，提取最核心的原理，方便快速理解。

一、ECDHE密钥协商协议
第三方工具、攻击者完全无法获取密钥。

client server
+-------------------------------------------+-----------------------------------
| <---- 0. 双方随机约定一些公开参数 ------> |
| 1. 生成随机私钥 client_priv
| 2. 基于client_priv，计算公钥 client_pub
| 3. 发送公钥 client_pub ------------>
 | 4. 接收公钥 client_pub
 | 5. 生成随机私钥 server_priv
 | 6. 基于server_priv，计算公钥 server_pub
 <------------ | 7. 发送公钥 server_pub
| 8. 接收公钥 server_pub
| 9. 基于client_priv，server_pub，计算密钥
 | 10. 基于server_priv，client_pub，计算密钥
（第9步和第10步，可以计算出相同的密钥）

简单举个例子
client server
+-------------------------------------------+-----------------------------------
| <----- 0. generate and send (2,11) ----> |
| 1. generate 8
| 2. caculate (8 * 2) % 11 = 5
| 3. send 5 ---------->
 | 4. receive 5
 | 5. generate 10
 | 6. caculate (10 * 2) % 11 = 9
 <------------ | 7. send 9
| 8. receive 9
| 9. key = (8 * 9) % 11 = 6
 | 10. key = (10 * 5) % 11 = 6

攻击者：截获网络流量，获取2,11,5,9，无法计算出密钥为6

二、RSA密钥交换协议

海量透明加密设计

Mon, 23 Mar 2026 20:52:00 +0800

1 透明加密

1.1 功能简述

关于透明加密的基本概念，请看需求文档。
用户使用透明加密的示例如下：

CREATE TABLE t1 (c1 TEXT, c2 TEXT);

CREATE ENCRYPTION KEY tde_key WITH (source=local, password='pass.123');
CREATE ENCRYPTION POLICY ep1 FRO t1 KEY tde_key;

INSERT INTO t1 VALUES ('data1', 'data2');
INSERT INTO t1 VALUES ('data1', 'data2');
SELECT * FROM t1;

1.2 实现方案

1.2.1 整体架构

透明加密的核心目标，是通过数据加密方案，解决攻击者绕过数据库安全机制，直接从磁盘窃取数据的问题。
在加密数据后，需要确保不影响内核在数据上进行计算。因此，需要在存储层底层，对数据进行加密。另外，为确保存储底层能够识别哪些数据加密，哪些数据不加密，以及使用什么算法加密等，上层需传递加密信息。透明加密逻辑架构如下：

1.2.2 工作流程

为适配存储底层设计，同时兼顾加密性能，以Page为粒度进行加密，并且，在Page中，存储加密信息。

1.2.3 详细流程

一、启动进程

在启动进程阶段，故障恢复时，如果回放到属于加密表的xlog，涉及到解密Page，因此，需在故障恢复前加载密钥。

main # 1. 启动数据库进程（基于pg-16代码）
 PostmasterMain # 2. 启动postmaster进程
 SelectConfigFiles # 3. 读取GUC文件
 'tde_load_encryption_key' # 4. 读取密钥文件（后文介绍密钥如何生成）
 SysLogger_Start
 StartupDataBase # 5. 开始故障恢复
 StartupProcessMain
 StartupXLOG
 ReadControlFile
 PerformWalRecovery
 for loop:
 ReadRecord # 6. 读取xlog
 ApplyWalRecord # 7. 重放xlog
 GetRmgr.rm_redo
 ...
 heap_xlog_insert
 XLogReadBufferForRedo
 XLogReadBufferForRedoExtended
 XLogReadBufferExtended
 ReadBufferWithoutRelcache
 ReadBuffer_common
 smgrread # 8. 读取数据文件
 # 需解密，后文统一介绍
 ServerLoop
 for loop:
 ConnCreate
 BackendStartup
 BackendRun
 PostgresMain # 9. 启动postgres进程
 StartCheckpointer
 StartBackgroundWriter
 StartChildProcess
 AuxiliaryProcessMain
 BackgroundWriterMain # 10. 启动bgwriter进程

二、生成密钥

当前版本，所有表，使用同一个数据密钥。因此，暂时无需新增系统表，存储密钥对象。

海量 mac 设计

Mon, 23 Mar 2026 21:41:00 +0800

1 强制访问控制

1.1 功能简述

从实现的角度看，当用户执行SQL时，强制访问控制主要实现以下功能：

CREATE ACCESS POLICY ..：在系统表中，记录ACCESS POLICY，以及其中的LABLE等信息
CREATE TABLE ..：创建表时，如果设置acess_policy字段，则自动为表新增1列隐藏列，列名为access_label
INSERT ..：向表插入数据时，根据当前用户的write_label，自动为数据生成access_label列的值。
SELECT ..：从表查询数据时，根据当前用户的read_label，自动为查询语句添加过滤条件has_mac_permission(access_label, read_label)

另外，如果为表设置访问策略，需在索引中同时设置访问策略：

CREATE INDEX ..：自动为索引新增1列，列名为access_label

对于一些其他语法，也许单独适配，包括：

COPY ..：自动修改旧数据的access_label值

1.2 实现方案

1.2.1 整体流程

本文重点从源码角度，介绍强制访问控制策略如何基于隐藏列，实现强制访问控制，包括：创建、填充、匹配隐藏列等流程。
核心功能的大致流程如下：

User Vastbase Disk
+---------------------------------------------------+---------------------------------------------------------+
# 管理员
| 1. CREATE ACCESS POLICY .. LEVEL .. LABEL .. --> |
 | 2. 存储access policy至系统表vb_access_policy -->
 | 3. 存储access level至系统表vb_access_level -->
 | 4. 存储access label至系统表vb_access_label -->
| 5. CREATE TABLE .. (access_policy=..) --> |
 | 6. 识别是否设置access_policy
 | 7. 自动添加隐藏列access_label
 | 8. 存储access_policy至系统表pg_class -->
 | 9. 存储accessl_label定义至系统表pg_attribute -->
| 10. CREATE USER ..
 ACCESS POLICY .. READ LABEL .. WRITE LABEL --> |
 | 11. 存储access_policy, read_label, write_label至系统表pg_authid -->
# 普通用户
| 12. vsql -U username -W password --> |
| 14. set read_label = .. / write_label = .. --> |
 | 15. 查询pg_authid，判断read_label/write_label是否合法 <--
 | 16. 设置临时的read_label/write_label
 | 17. 如何用户未自动设置read_label/write_label，自动根据pgauthid设置
| 18. INSERT .. --> |
 | 19. 查询pg_class，判断表是否有access_policy <--
 | 20. 自动为隐藏列赋值，取值为write_label
| 21. SELECT .. --> |
 | 22. 查询pg_class，判断表是否有access_policy <--
 | 23. 语义分析
 | 24. 查询重写：自动新增过滤条件：WHERE has_mac_permission(access_label, read_label)
 | 24. 计划执行：扫描Tuple，根据过滤条件，过滤不满足权限检查的Tuple

1.2.2 详细流程

一、创建策略

当用户创建策略时，例如：

海量 15 设计逻辑复制性能优化

Wed, 06 May 2026 17:48:00 +0800

1 逻辑复制性能优化

1.1 功能简述

原理：
假设，发布端执行INSERT INTO t1 VALUES(1,'data1')，更改1行数据，产生1条wal日志。逻辑复制功能将读取这条wal，解码并生成1条message，将message发送至订阅端。订阅端应用这条message，等价于重新执行INSERT INTO t1 VALUES(1,'data1')。
问题：
308.1 psu1以及之前版本，逻辑复制性能较低。以tpcc场景为例，40w tmpc时，发布端产生wal日志速度约100m/s，订阅端的复制速度约10+m/s。
客户：
滚动升级场景中，备机停机升级，主机持续执行业务，备机升级后使用逻辑复制追赶主机数据。长存客户场景，主机产生wal日志速度约40-50m/s，旧版本逻辑复制速度10+m/s，由于逻辑复制速度太慢，备机无法追赶主机，最终导致升级失败。
优化
本需求设计与实现并行逻辑复制机制，大幅提高逻辑复制速度，在上述场景中，订阅端速度可达到70-90m/s。并行逻辑复制分为3个关键子机制：
1. 发布端多线程并行解码
2. 发布端与订阅端流复制传输协议
3. 订阅端多线程并行应用

1.2 实现方案

本章分3个章节，分别介绍3个关键子机制。

1.2.1 发布端并行解码机制

在旧版本中，发布端采用串行解码机制，只有1个walsender线程，串行执行：1次读取1条wal日志，解码1条wal生成1条message，缓存或发送message。

旧版本代码中，发布端有实现并行解码的代码，但是，无法直接使用，订阅端只能是工具，不能是数据库实例，且存在大量问题。本需求基于旧版本并行解码，实现权限的并行解码机制。

并行解码机制，将启动多个线程，包括1个reader、多个decoder、1个walsender，它们的功能如下：

reader：1次读取1条wal日志，将wal发送给decoder
decoder：1次接收1条reader发送的wal，解码生成message，将message发送给walsender
walsender：1次接收1条decoder发送的message，将message发送给订阅端

线程架构图如下：

lsn 1-10
 d1 1 4 collect 阻塞 1
 d2 2 5 2
 d3 3 6 3

1.2.2 发布端与订阅端流复制协议

一、握手阶段

订阅端与发布端建立连接时，订阅端会根据CRETE SUBSCRIPTION语法设置的参数，生成连接命令，根据连接命令，发布端和订阅端决定采用哪种通信协议，究竟是采用事务复制协议（旧版本）还是流复制协议（新版本）。

事务复制协议（旧版本）

订阅端发送的连接命令如下：

START_REPLICATION SLOT "$slot_name" LOGICAL $start_lsn
 (proto_version '3', publication_names '"$publication_name"')

流复制协议（新版本）

如果CRETE SUBSCRIPTION时，指定worker_number>1，即启用并行逻辑复制机制，将使用新的连接命令，订阅端发送的连接命令如下：

START_REPLICATION SLOT "$slot_name" LOGICAL $start_lsn
 (proto_version '3', publication_names '"$publication_name"'， streaming 'extreme', parallel-decode-num '20', max-recordbuffer-in-memory '100', max-txn-in-memory '100')

上述命令中新增了多个参数：

设计文档 on Kernel Notes

海量 1 设计 oracle加密函数

1

海量 2 设计 profile

1 Oracle兼容性-支持profile功能

1.1 功能简述

1.2 实现方案

一、元数据

海量 2 设计 oracle profile

2

参数1: failed_login_attempts

参数2: password_lock_time

参数3: password_effect_time

参数4: password_reuse_max

参数5: password_reuse_time

海量 5 设计 G100审计

G100审计功能重构

1 功能简述

2 实现方案

一、审计架构

二、工作流程

三、详细流程

阶段1 配置审计（进程启动）

阶段2 设置范围

海量 5 方案 G100审计重构

1 审计特性介绍

1.1 核心功能

海量 6 设计 greenplum

1 需求分析

1.1 透明加密

1.2 动态脱敏

1.3 全密态

1.4 防篡改

2 greenplum

WAL 加密模块设计

1 威胁模型

1.1 为什么不用 dm-crypt 了事

1.2 FPI 是必须堵的洞

海量 9 设计 E100审计

1 E100审计功能

1.1 功能简述

1.2 实现方案

一、启动审计进程

二、收集审计事件

分享编写需求/设计文档的个人经验

1 简介

1.1 分享的主题

1.2 分享的背景

1.3 前公司的流程

2 需求文档写作思路

2.1 分析过程

海量 10 设计 SSL协议

1 TLS协议支持第三方流量审计

1.1 功能简述

1.2 实现方案

一、ECDHE与RSA的区别

海量 透明加密 设计

1 透明加密

1.1 功能简述

1.2 实现方案

1.2.1 整体架构

1.2.2 工作流程

1.2.3 详细流程

一、启动进程

二、生成密钥

海量 mac 设计

1 强制访问控制

1.1 功能简述

1.2 实现方案

1.2.1 整体流程

1.2.2 详细流程

一、创建策略

海量 15 设计 逻辑复制性能优化

1 逻辑复制性能优化

1.1 功能简述

1.2 实现方案

1.2.1 发布端并行解码机制

1.2.2 发布端与订阅端流复制协议

一、握手阶段

事务复制协议（旧版本）

海量透明加密设计

海量 15 设计逻辑复制性能优化