Re: [v9.2] Object access hooks with arguments support (v1) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] Object access hooks with arguments support (v1)
Date
Msg-id CA+TgmoaBrgDk7MjUWSBkC9AuzgQMSgSu8_k4S1vBjZLnxnW-PA@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] Object access hooks with arguments support (v1)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] Object access hooks with arguments support (v1)
List pgsql-hackers
On Tue, Oct 18, 2011 at 11:25 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> For example, I hope sepgsql to perform as follows when user create a new table.
> - It computes a default security label that needs Oid of the namespace.
> - It checks db_table:{create} permission on the security label being computed.
> - In addition, it checks db_table:{insert} permission when SELECT INTO
> - Also, it checks these permissions on columns being newly created.
> - However, It does not check permissions when the tables are internally created,
>  such as toast tables or temporary relations created by make_new_heap().

That's superficially reasonable, but I don't feel good about passing
is_select_info to the object access hook here.  If insert permission
is required there, then it ought to be getting checked by selinux at
the same place that it's getting checked for at the DAC level.  If we
get into a situation where sepgsql is checking permissions using some
system that's totally different from what we do for DAC, I think
that's going to produce confusing and illogical results.  This is
ground we've been over before.  Similarly with fdw_srvname.  The only
excuse for passing that is to handle a permissions check for foreign
data wrappers that isn't being done for DAC: if there is a DAC
permissions check, then the MAC one should be done there also, not
someplace totally different.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_ctl restart - behaviour based on wrong instance
Next
From: Fujii Masao
Date:
Subject: Re: pg_ctl restart - behaviour based on wrong instance