Re: [v9.2] Object access hooks with arguments support (v1) - Mailing list pgsql-hackers
From | Kohei KaiGai |
---|---|
Subject | Re: [v9.2] Object access hooks with arguments support (v1) |
Date | |
Msg-id | CADyhKSUy6r80b9x+EkGWZd3Ymm95OpUtBhFHy8+CaS8eO3dRkQ@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 |
I'm under works on the prep-object-creation hook with contextual arguments that are commonly used to existing DAC checks. One heahache of mine is that some object classes takes long distance to collect all the information being necessary on creation check; such as DefineType(). In this function, it checks superuser privilege (and CREATE on the namespace implicitly), then it makes a shell type or a base type after name resolve of type handlers (that also checks ownership of functions implicitly). It means the place where we can put a prep-creation hook is restricted to the point next to all the oid of type-handlers are looked-up, however, it is too late to apply checks before TypeShellMake(). I hope to make clear the matter again. The reason why we didn't want to put permission check on OAT_POST_CREATE hook is that it takes random flags (like "is_select_into") on its argument to avoid unnecessary permission checks. If sepgsql would apply permission checks db_procedure:{install} on the OAT_POST_CREATE hook based on the funcion-oid within new entry of system catalog, we can relocate OAT_PREP_CREATE hook more conceptually right place, such as just after the pg_namespace_aclcheck() of DefineType(). On the other hand, we may need to answer why these information are NOT delivered on the OAT_PREP_CREATE hook without knowledge of sepgsql internal. Please some ideas. Thanks, 2011/11/1 Kohei KaiGai <kaigai@kaigai.gr.jp>: > 2011/11/1 Robert Haas <robertmhaas@gmail.com>: >> On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >>> I tried to summarize permission checks of DAC/MAC on several object classes >>> that are allowed to assign security label right now. >>> http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Permissions >>> >>> In most of checks, required contextual information by SELinux are commonly >>> used to DAC also, as listed. >> >> What's up with this: >> >> "a flag to inform whether CASCADE or RESTRICT" >> >> That doesn't seem like it should be needed. >> > Ah, it is needed to determine the scope of objects to be deleted. > If a table being referenced by views, deletion of this table with cascade > involves the views, even if these are owned by others. > DAC does not check permissions to drop on depending objects, > so, it is a headache for me. > > However, the worth of drop permission checks on involved objects > is not perfectly clear, because the user is allowed to drop the table > being reference by views at least in above example. If so, views to > reference non-existent table is nonsense. > I'm not 100% sure why existing DAC does not check permissions > on depending objects even if these are owned by other users. > I'd like to know the reason of this behavior. > >> We should consider whether CREATE TABLE should be considered to >> consist of creating a table and then n attributes, rather than trying >> to shove the attribute information wholesale into the create table >> check. >> > I don't see tangible difference between them except for simpleness of > implementation. One point we should consider is the timing to store > security label of table and columns. > > If creation checks of table/columns are consolidated into one hook, > we can check permissions to create them and write-back default > security labels of them into one private datum to be delivered to > post-creation hook. > > If creation checks of table/columns are separated into individual > invocation, the later column-checks needs security label of the > new table as contextual information, however, it requires us to > know internals of sepgsql why it needs table's label to check > permission to create a column, because both of checks shall > be done DefineRelation / OpenIntoRel prior to heap_create_with_catalog > that invokes post-creation hook. > > So, I think it works better with the approach that also delivers > TupleDesc on creation of relation checks, rather than separated > invocations. > > Thanks, > -- > KaiGai Kohei <kaigai@kaigai.gr.jp> > -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
pgsql-hackers by date: