【PostgreSQL观察】第36回 PostgreSQL的安全补丁（一）（简体）

更新:2007-05-12
對映章節:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270174/

翻译自石井达夫先生的文章

新的安全漏洞
在PostgreSQL观察第35回，传达了来自核心开发成员的安全补丁发表预告以及关于SECURITY DEFINER函数（可以使用其他用户权限的函数）的安全警告，这次新发现的安全漏洞正是与SECURITY DEFINER有关。

SCHAMA搜索路径（search path）的问题
在讨论本次发现的安全漏洞之前，我们先复习一下上回提到的“安全警告”，他们的根源是一样的。
PostgreSQL中有Schema的概念，也就是命名空间，在不同的schema中可以创建名字相同的数据表，这就像在UNIX中可以在不同目录下创建同名文件一样。它有两种用法：
一种是显式指定schema名：public.t1指定public schema下的t1对象。
另一种方法是 使用schema search path，指定当省略schema名称的时候，优先使用哪一个schema。可以用“show search_path”命令来确认当前的 schema search path：
test=> show search_path;
search_path
----------------
"$user",public
(1 row)
这个例子显示以当前登陆用户名为第一优先schema名称，然后是名为public的schema。顺便提一下public这个特殊schema，它是缺省的schema，如果什么也不指定的话，对象将被建立在public中。

利用pg_catalog schema的攻击
除此之外还有持有系统catalog、聚集函数（aggregate）、操作符（operator）的pg_catalog schema，即使它没有包含在搜索路径中一般也被当作搜索对象，并经常被最先搜索。因为所有的聚集函数和操作符都被pg_catalog持有，这样的考虑是适当的。
但是如果显式将pg_catalog放到搜索路径中的话，将以指定的顺序进行搜索。如果事先准备与pg_catalog中的聚集函数和操作符同名的对象，pg_catalog中登录的“正规”对象会被替代。这样，SECURITY DEFINER函数中使用的对象可以被替换为恶意用户提供的对象，以他人的权限实施攻击。
相应的对策是，在SECURITY DEFINER函数的搜索路径中仅仅设定安全的schema。
上次说提出的“安全警告”正是这样。