Re: Prep object creation hooks, and related sepgsql updates
От | Kohei KaiGai |
---|---|
Тема | Re: Prep object creation hooks, and related sepgsql updates |
Дата | |
Msg-id | CADyhKSV6zdSKoH19dYaaE-t_B3wSqCu1Km_tAbJGNn62B-+vTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prep object creation hooks, and related sepgsql updates (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Prep object creation hooks, and related sepgsql updates
|
Список | pgsql-hackers |
2011/11/27 Dimitri Fontaine <dimitri@2ndquadrant.fr>: >> And, it seems to me the current proposition of the command trigger >> does not support to fire triggers on creation of databases, although >> permission checks requires Oid of source database that is not also >> appeared in pg_database catalog. > > I have to have a look at what forbids us to add support for the create > database command here. It seems to be just another branch of the switch > in standard_ProcessUtility(). > I'm not sure what arguments shall be provided to the guest of command triggers. And, I'd like to mention about its specification should not depend on details of particular modules; according to the previous discussion. After the long discussion, one concensus is that prep-creation hook shall be deployed around existing DAC checks and it takes arguments that are also referenced at the existing DAC; such as oid of source database on creation of databases. I also checked security model between DAC and MAC, and I concluded most of them takes common information to make its decision. It is a hard to answer question whether we can implement sepgsql on the upcoming command trigger feature; without information about where its hooks shall be deployed and what arguments are provided. :-( >>> I don't think schemaname+objectname fails to be unique, so I don't think >>> you need another kind of Oid in BEFORE creation triggers here. >>> >> The pg_seclabel and pg_shseclabel needs OID to assign a security label >> on a particular database object, so label provider (sepgsql) must know >> Oid of the target object on assignment time. > > Yes, and you need to refer to things you did in the BEFORE trigger from > the AFTER trigger, I'm just offering you a way to do that. Then if you > need the Oid in the AFTER trigger, of course you have it. > How does it inherit an opaque private initialized at BEFORE trigger to AFTER trigger? I checked your patch, however, it seems to me it does not have a mechanism to deliver something between BEFORE and AFTER. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: