PostgreSQL的函数安全定义解说

周正中 2015-10-21 15:46:00
 

上周,由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

 

 

 

本文由作者周正中授权DBA+社群发布,选自作者网易博客PostgreSQL research

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告