Re: [v9.2] Object access hooks with arguments support (v1)
От | Robert Haas |
---|---|
Тема | Re: [v9.2] Object access hooks with arguments support (v1) |
Дата | |
Msg-id | CA+TgmoaBrgDk7MjUWSBkC9AuzgQMSgSu8_k4S1vBjZLnxnW-PA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.2] Object access hooks with arguments support (v1) (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.2] Object access hooks with arguments support (v1)
|
Список | 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 по дате отправления: