上周，由DBA+杭州群联合发起人周正中分享的PostgreSQL使用安全指导性文章，让大家在数据库的加固操作上受益匪浅。而本周，他将分享关于PostgreSQL的函数安全定义解说。

 

专家简介

  

周正中

网名：德哥@Digoal

DBA+杭州群联合发起人之一

 

PostgreSQL中国社区发起人之一，负责杭州分会，兼任社区CTO一职。曾就职于斯凯网络，负责数据库部门。现就职于阿里巴巴，负责RDS PG内核组事务。

 

 

 

PostgreSQL函数可以设置被调用时的角色，以及参数。详细的语法如下：

 

 

当函数被调用时，可以选择以创建函数的角色执行函数，或者以调用者的角色执行函数（默认）。

 

同时，我们还可以设置函数被调用时的参数。

 

我们可以跟踪一下，跟踪角色需要用到session_user和current_user，这两者的差别可参考如下代码：

 

src/backend/utils/init/miscinit.c

 

session_user是指登陆数据库时的角色或者被SET SESSION AUTHORIZATION设置的角色。

 

current_user是指set role设置的角色，或者继承自session user，或者是函数调用时定义的角色。

 

举个例子，先搞明白这两个用户的含义：

 

 

创建测试函数：

 

 

这里的security definer表示调用函数时，使用函数owner的权限进行调用。

 

set search_path to 'public'，表示在调用函数时，使用这个值作为search_path。

 

 

使用digoal用户连接到postgres数据库，并调用postgres.f1()函数：

 

 

从NOTICE可以看到我们对函数的设置起作用了。search_path是我们设置的public，而不是默认的 "$user",public。

 

current_role则是函数的definer postgres。

 

 

因此我们使用security definer时，需特别注意，因为可能造成权限升级，例如本文使用超级用户创建的security definer函数。

 

我们把这个函数的security改为invoker。再次使用digoal调用f1()，可以看到current_role是digoal了。

 

 

下面举个例子，说明security definer的不安因素。使用超级用户创建一个函数如下，用于检查用户是否通过密码认证。

 

 

但是如果设置为security definer，想想有什么安全隐患呢？

 

 

这样看貌似没有隐患，但是因为函数中没有使用schema.table的方式，所以我们可以使用普通用户自己建立一张认证表，并自定义search_path来修改扫描优先级，来通过认证，甚至可以使用临时表的SCHEMA，都不需要修改search_path（因为临时表schema优先级被排在最前），偷偷就搞定了。

 

 

为了提高security definer函数的安全性。可以有以下方法。

 

1. 建议在里面使用的函数或表等一切对象，都使用schema强制指定。

 

2. 设置search_path, 防止普通用户钻空子。

 

例如：

 

 

现在钻不了空子了：

 

 

或者在调用函数时使用设置的search_path，将普通用户能创建表的schema都去除。

 

 

现在也安全了：

 

 

不过这里还是推荐在函数中使用schema，防止这类问题。

 

 

 

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2015-10-21