上周，由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，防止这类问题。

【参考】

1. http://www.postgresql.org/docs/9.5/static/sql-createfunction.html

2. src/backend/utils/init/miscinit.c