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

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(at)kaigai(dot)gr(dot)jp>:
> 2011/11/1 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>