函数调用设置

【DBA+数据库安全专题】PostgreSQL的函数安全定义解说

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

上周，由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优先级被排在最前），偷偷就搞定了。