From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.2] Object access hooks with arguments support (v1) |
Date: | 2011-10-18 16:22:02 |
Message-ID: | CA+TgmoaBrgDk7MjUWSBkC9AuzgQMSgSu8_k4S1vBjZLnxnW-PA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 18, 2011 at 11:25 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-10-18 16:22:44 | Re: pg_ctl restart - behaviour based on wrong instance |
Previous Message | Fujii Masao | 2011-10-18 16:20:29 | Re: pg_ctl restart - behaviour based on wrong instance |