Re: [v9.2] Object access hooks with arguments support (v1)

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

In response to

Responses

Browse pgsql-hackers by date

  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