fix

Author: digoal

202403/20240308_01.md

@@ -12,6 +12,8 @@ PostgreSQL , PolarDB , DuckDB , 备份 , 恢复 , 数据文件 , 隐藏隐患
 ----                                                                        
                                                                         
 ## 背景     
+
+## 挖个坑
 今天是女神节, 分析一下老白一篇关于PG数据文件被删除还能使用的文章:    
 https://mp.weixin.qq.com/s/4wX0KOiRXq0JJRLoSmgxhA  
 
@@ -40,14 +42,14 @@ https://mp.weixin.qq.com/s/4wX0KOiRXq0JJRLoSmgxhA
 - 如果我们去查a表, 它的数据当然可能是不准确的.    
 
 
-回过头来看老白的文章里提到的场景, 其实和上面部分表空间备份与恢复的情况类似.    
+回过头来看老白的文章里提到的场景, 和上面部分表空间备份与恢复的情况类似.    
 - PG规定了单个数据文件的大小上限, 当数据超过一个数据文件大小, 会写append文件, 文件suffix按数字编号, 如`17889`, `17889.1`, `17889.2` .    
 - 我们删除一个在最近一次检查点之后没有被DML过、也没有被vacuum过、也没有修改过hint bit的数据文件的append文件.    
 - 如果进行count操作, 是发现不了的.   
 - 但是索引查询引用到被删除的文件内的坏块时可以被发现.    
 
 
-## 怎么解决?  
+## 填坑  
 
 1、发现坏块: 检查坏块, 开启checksum, 有现成的工具. pg_checksums    
 2、发现文件被删: 检查元数据和数据文件映射的完备性.  这个通常可以启动时检查, 目前社区没有该功能, 需要提patch. 或者运行过程中检查, 发现完备性问题, 应该要有报错.   
@@ -58,10 +60,23 @@ pg_relation_filepath
 pg_filenode.map   
 ```  
 
-## 挖坑  
+## 再挖坑  
 Oracle, 默认未开启fpw. 也有比较难发现的隐藏风险.   
 
 如果服务器崩溃, 可能出现partial write的块. 这种数据块也是极难发现, 只有读到时通过块的checksum才会校验出错误. 恢复则需要用到过去的全量备份和redo. 如果你的备份保留时间不够长, 当你发现时可能备份已经被清理了, 那就恢复不回来了.    
+      
+黑盒产品(如O)自发觉的功能有可行基础，因为你不知道它怎么组织数据的, 你无法模拟它的行为来修改内容.  
+  
+开源的产品, 理论上都可以模拟符合数据库逻辑的操作行为。开源产品要么使用加密数据文件，没有得到密钥无法模拟，被篡改可以被发现。不过发现篡改的成本比较高，增加了额外的IO和计算。
+  
+操作系统被黑之后, 可以写点“坏tuple”进去，checksum也可以刷新，非常逼真。通过checksum就无法发现被篡改. 
+  
+老白说oracle段页式这方面好很多，BMB里有所有extent的信息bnb坏了也会报错. 实际上即使你把checksum放宽到page+extent+file级别, 都是可以被修改的, 只要代码公开, 攻击者就可以根据你设置的checksum位置去进行篡改, 而且对于产品来说, checksum越多性能肯定越差.  
+  
+所以开源产品要根本上解决这个场景存在的问题, 至少要上TDE(透明加密) 以及 自发觉。 就是结合客户端给的密钥进行加密, 校验时也需要这个密钥, 所以一旦被篡改就会被发现. 自发觉则需要主动发现问题及报错.  
+  
+好消息, PolarDB for PostgreSQL开源版本支持了TDE.  
+