PostgreSQL CVE-2018-1058 问题？

简 介

在之前的版本中，PgSql 在不同表空间下新建名称相似的对象时，会对其他用户查询该对象时造成不可预知的错误就想特洛伊木马病毒似的。

什么是 CVE-2018-1058？

在PgSql 7.3版本中介绍了”schemas”，在不同的命名空间允许用户创建对象或者函数等。

Catalog 和 Schema ：可理解为一个容器或者数据库对象命名空间,解决命名冲突问题*

1个数据库---->N个Catalog 
1个Catalog----->N个Schema 
1个Schema---->N个数据库对象（表、视图、字段等）

PgSql**默认为用户创建一个**public 表空间，所有用户默认创建的对象、函数等都在该命名空间下。
如下查询是相等的：

SELECT * FROM table_a;
SELECT * FROM public.table_a;

PgSql 管理员可以对在特定schema的用户进行授权（grant 和revoke)

Schemas 允许用户在同一数据库下不同schema 下命名相同的名称对象、函数等，在这种情况下PgSql 决定通过search_path.setting 设置来取决于哪个对象或者函数被使用。

search_path.setting 指定了在schemas下该对象被查询时的顺序。

search_path.setting 默认值为$user,public ，$user指的是当前执行查询操作的用户

如：

CREATE TABLE alice.a AS SELECT 1::int AS id;
CREATE TABLE public.a AS SELECT 'a'::text AS id;

若当前执行查询的为 alicce 则执行”SELECT * FROM a; “

SELECT * FROM a; 
id 
----
 1

不管 search_path 的内容，PgSql查询系统目录pg_catalog,判断当前是否有匹配查询的对象，如果有，在pg_catalog中查询对象,没有指定search_path，则会先查询pg_catalog下匹配的对象。

CVE-2018-1058 的问题？

问题：主要是发生在默认的 public 表空间下。PgSql如何使用search_path设置，这个能力
search_path默认会查询当前执行查询操作的用户，另一个用户在此时插入数据，则当前对象
就会查询到另一个用户插入的对象值，导致问题产生。

如官网例子：

There are two database users, alice and bob who both have access to the same database that contains the default public schema and a table in that schema with the following definition:
CREATE TABLE a (full_name varchar(255));
In the application that both alice and bob work on, there is a line of code that both users execute to return the names from table a as lowercase strings, i.e.
SELECT lower(full_name) FROM a;
The lower function is defined in the pg_catalog schema and accepts a single argument of type text. The PostgreSQL query parser knows that it can cast full_name from type varchar to text and thus use the lower function.
Knowing that the system has only the default public schema set up, user alice decides to create the following function in the public schema:
CREATE FUNCTION lower(varchar) RETURNS text AS

$$SELECT 'ALICE WAS HERE: ' || $1;$$ LANGUAGE SQL IMMUTABLE;
Though there is a function named lower in the pg_catalog schema, the above function is created successfully in the public schema as it is namespaced in a different location.
Additionally, the lower function in the public schema is a better fit for data in the full_name column, and thus if bob tries to run the following query:
SELECT lower(full_name) FROM a;
He will end up seeing a surprise message from alice indicating that she “was here” in addition to the expected return data. Thus, alice has successfully inserted a trojan function.

上述官网例子：
即同一个数据库，当不同用户同时在线执行查询同一函数时，默认会查找public表命名空间下的该函数。当用户在查询时，此时另一用户修改该命名空间下的函数或者创建名称相同的函数时，就会导致另一用户查询调用该函数，导致出现上述问题。

CREATE TABLE a (full_name varchar(255));

对于ALICE 和 Bob 同时执行：

SELECT lower(full_name) FROM a;

其中 lower() 函数在默认的public表空间下 ，此时ALICE 修改或者创建同名函数如：

CREATE FUNCTION lower(varchar) RETURNS text AS $$
    SELECT 'ALICE WAS HERE: ' || $1;
 $$ LANGUAGE SQL IMMUTABLE;

此时Bob执行

SELECT lower(full_name) FROM a;

会调用的是ALICE 刚刚创建的同名函数，即会返回结果 ALICE

如何避免该问题？

a、禁止用户在默认的public表空间下创建新对象，则超级管理员在所有数据库执行：

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

查看是否存在相同或者类似名称在 public 或者 pg_catalog

\df public.*

查看pg_catalog下定义的函数

\df pg_catalog.*

b、超级管理员对数据库用户 search_path设置默认值

ALTER ROLE username SET search_path = "$user";

或者修改 postgresql.conf 中 参数search_path的值为”$user”