通过PostgreSQL中的视图和触发器跟踪当前用户


11

我有一个PostgreSQL(9.4)数据库,该数据库根据当前用户限制对记录的访问,并跟踪用户所做的更改。这是通过视图和触发器实现的,并且在大多数情况下都可以正常工作,但是我在需要INSTEAD OF触发器的视图中遇到了问题。我试图减少问题的发生,但是我很抱歉这仍然很长。

情况

与数据库的所有连接都是通过Web前端通过单个帐户进行的dbweb。连接后,通过SET ROLE使用Web界面更改角色以使其与该人相对应,并且所有这些角色都属于组角色dbuser。(有关详细信息,请参见此答案)。假设用户为alice

我的大多数表都放在一个架构中,在这里我将对其进行调用private并属于dbowner。这些表不能直接访问dbuser,但可以用作另一个角色dbview。例如:

SET SESSION AUTHORIZATION dbowner;
CREATE TABLE private.incident
(
  incident_id serial PRIMARY KEY,
  incident_name character varying NOT NULL,
  incident_owner character varying NOT NULL
);
GRANT ALL ON TABLE private.incident TO dbview;

特定行对当前用户的可用性alice由其他视图确定。一个简化的示例(可以减少,但需要通过这种方式来支持更一般的情况)将是:

-- Simplified case, but in principle could join multiple tables to determine allowed ids
CREATE OR REPLACE VIEW usr_incident AS 
 SELECT incident_id
   FROM private.incident
  WHERE incident_owner  = current_user;
ALTER TABLE usr_incident
  OWNER TO dbview;

然后,通过dbuser角色可以访问的视图提供对行的访问,例如alice

CREATE OR REPLACE VIEW public.incident AS 
 SELECT incident.*
   FROM private.incident
  WHERE (incident_id IN ( SELECT incident_id
           FROM usr_incident));
ALTER TABLE public.incident
  OWNER TO dbview;
GRANT ALL ON TABLE public.incident TO dbuser;

请注意,因为在FROM子句中仅出现一个关系,所以这种视图是可更新的,没有任何其他触发器。

为了进行日志记录,存在另一个表来记录更改的表以及更改的人。简化版本为:

CREATE TABLE private.audit
(
  audit_id serial PRIMATE KEY,
  table_name text NOT NULL,
  user_name text NOT NULL
);
GRANT INSERT ON TABLE private.audit TO dbuser;

这是通过放置在我希望跟踪的每个关系上的触发器填充的。例如,private.incident仅限于插入的示例是:

CREATE OR REPLACE FUNCTION private.if_modified_func()
  RETURNS trigger AS
$BODY$
BEGIN
    IF TG_OP = 'INSERT' THEN
        INSERT INTO private.audit (table_name, user_name)
        VALUES (tg_table_name::text, current_user::text);
        RETURN NEW;
    END IF;
END;
$BODY$
  LANGUAGE plpgsql;
GRANT EXECUTE ON FUNCTION private.if_modified_func() TO dbuser;

CREATE TRIGGER log_incident
AFTER INSERT ON private.incident
FOR EACH ROW
EXECUTE PROCEDURE private.if_modified_func();

因此,如果现在alice插入public.incident,一条记录将('incident','alice')出现在审核中。

问题

当视图变得更加复杂并且需要INSTEAD OF触发器来支持插入时,这种方法会遇到问题。

假设我有两个关系,例如表示涉及多对一关系的实体:

CREATE TABLE private.driver
(
  driver_id serial PRIMARY KEY,
  driver_name text NOT NULL
);
GRANT ALL ON TABLE private.driver TO dbview;

CREATE TABLE private.vehicle
(
  vehicle_id serial PRIMARY KEY,
  incident_id integer REFERENCES private.incident,
  make text NOT NULL,
  model text NOT NULL,
  driver_id integer NOT NULL REFERENCES private.driver
);
GRANT ALL ON TABLE private.vehicle TO dbview;

假设我不想公开除的名称之外的详细信息private.driver,因此有一个连接表并投影我想公开的位的视图:

CREATE OR REPLACE VIEW public.vehicle AS 
 SELECT vehicle_id, make, model, driver_name
   FROM private.driver
   JOIN private.vehicle USING (driver_id)
  WHERE (incident_id IN ( SELECT incident_id
               FROM usr_incident));
ALTER TABLE public.vehicle OWNER TO dbview;
GRANT ALL ON TABLE public.vehicle TO dbuser;

为了alice能够插入到该视图中,必须提供触发器,例如:

CREATE OR REPLACE FUNCTION vehicle_vw_insert()
  RETURNS trigger AS
$BODY$
DECLARE did INTEGER;
   BEGIN
     INSERT INTO private.driver(driver_name) VALUES(NEW.driver_name) RETURNING driver_id INTO did;
     INSERT INTO private.vehicle(make, model, driver_id) VALUES(NEW.make_id,NEW.model, did) RETURNING vehicle_id INTO NEW.vehicle_id;
     RETURN NEW;
    END;
$BODY$
  LANGUAGE plpgsql SECURITY DEFINER;
ALTER FUNCTION vehicle_vw_insert()
  OWNER TO dbowner;
GRANT EXECUTE ON FUNCTION vehicle_vw_insert() TO dbuser;

CREATE TRIGGER vehicle_vw_insert_trig
INSTEAD OF INSERT ON public.vehicle
FOR EACH ROW
EXECUTE PROCEDURE vehicle_vw_insert();

这样做的问题是,SECURITY DEFINER触发函数中的选项使它在current_user设置为的情况下运行dbowner,因此,如果alice将新记录插入到视图中,则private.audit记录中作者要成为的对应条目dbowner

因此,有没有一种方法可以保留current_user而不赋予dbuser组角色直接访问架构中关系的权限private

部分解决方案

正如Craig所建议的那样,使用规则而不是触发器可以避免更改current_user。使用上面的示例,可以使用以下内容代替更新触发器:

CREATE OR REPLACE RULE update_vehicle_view AS
  ON UPDATE TO vehicle
  DO INSTEAD
     ( 
      UPDATE private.vehicle
        SET make = NEW.make,
            model = NEW.model
      WHERE vehicle_id = OLD.vehicle_id
       AND (NEW.incident_id IN ( SELECT incident_id
                   FROM usr_incident));
     UPDATE private.driver
        SET driver_name = NEW.driver_name
       FROM private.vehicle v
      WHERE driver_id = v.driver_id
      AND vehicle_id = OLD.vehicle_id
      AND (NEW.incident_id IN ( SELECT incident_id
                   FROM usr_incident));               
   )

这样保存current_user。不过,支持RETURNING条款可能有些毛茸茸。此外,我找不到一种安全的方法来使用规则同时插入两个表中以处理的使用driver_id。最简单的方法将是使用WITH中的条款INSERT(CTE),但这些都不是会同允许的NEW(错误:rules cannot refer to NEW within WITH query),留下一个诉诸lastval()这是强烈反对

Answers:


4

因此,有没有一种方法可以保留current_user,而无需授予dbuser组角色直接访问架构私有关系的权限?

您可能可以使用规则而非INSTEAD OF触发器来通过视图提供写访问权限。意见始终与视图创建,而不是查询用户的安全权限行事,但我并不 current_user改变。

如果您的应用程序直接以用户身份连接,则可以检查session_user而不是current_user。如果您随后与一般用户连接,这也将起作用SET SESSION AUTHORIZATION。但是,如果您以普通用户身份连接SET ROLE到所需用户,则将无法使用。

无法从SECURITY DEFINER功能中获取前一个用户。您只能获得current_usersession_user。一种获取last_user用户身份或一堆用户身份的方法会很好,但是目前不支持。


啊哈,以前没处理过规则,谢谢。SET SESSION可能会更好,但我认为初始登录用户将需要具有超级用户特权,这听起来很危险。
贝尔达兹2015年

@beldaz是的。这是的大问题SET SESSION AUTHORIZATION。我确实希望在和之间找到一些东西SET ROLE,但目前还没有这样的东西。
Craig Ringer

1

这不是一个完整的答案,但不适合评论。

lastval()currval()

是什么让您认为lastval()灰心呢?似乎是一种误会。

引用的答案中,Craig强烈建议使用触发器而不是注释中的规则。我同意-显然,除了您的特殊情况。

回答强烈不鼓励使用的currval()-但是,这似乎是一个misundertstanding。没错,lastval()或者说没有错currval()。我对引用的答案发表了评论。

引用手册:

currval

返回nextval当前会话中为此序列最近获得的值。(如果nextval从未在此会话中为此序列调用,则报告错误。)由于此方法返回的是会话本地值,因此它提供了一个可预测的答案,即nextval自当前会话执行以来是否执行了其他会话。

因此,这对于并发事务是安全的。唯一可能的复杂性可能是由于其他触发器或规则可能会无意间调用同一触发器-这是极不可能的情况,您可以完全控制要安装的触发器/规则。

但是,我不确定命令顺序是否保留在规则内(即使它currval()是volatile函数)。另外,多行INSERT可能会使您不同步。您可以将RULE分为两个规则,只有第二个是INSTEAD。请记住,根据文档:

同一表和同一事件类型上的多个规则以字母名称顺序应用。

我没有及时进行进一步调查。

DEFAULT PRIVILEGES

至于:

SET SESSION AUTHORIZATION dbowner;
...
GRANT ALL ON TABLE private.incident TO dbview;

您可能会感兴趣:

ALTER DEFAULT PRIVILEGES FOR ROLE dbowner IN SCHEMA private
   GRANT ALL ON TABLES TO dbview;

有关:


谢谢,我对lastval和的理解确实是错误的currval,因为我没有意识到它们在会议中是本地的。实际上,我确实在我的实际模式中使用默认特权,但是每个表的特权来自复制和粘贴的转储数据库。我得出的结论是,重组关系比弄乱规则要容易得多,尽管它们是如此整洁,因为我以后会看到它们令人头疼。
beldaz 2015年

@beldaz:我认为这是一个很好的决定。您的设计变得太复杂了。
Erwin Brandstetter
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.