Re: security hook on table creation - Mailing list pgsql-hackers

(2010/10/12 23:09), Robert Haas wrote:
> On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei<kaigai@kaigai.gr.jp>  wrote:
>> As I introduced before, the idea of two hooks makes obvious where
>> we should put the security hooks; it is next to the existing DAC
>> checking. It is the best guideline, even if we will touch the code
>> around object creation in the future version.
>>
>> If the creation-hook would be put on the place far from existing
>> DAC checks, what provides us a guideline to deploy security hooks?
>> It seems to me the idea of only post-creation hook try to lose
>> this kind of benefit instead of half dozen of exceptions.
>>
>> I think MVCC visibility is just an actualization of the matters.
>> The point is that we can be released from the task to consider
>> where is the right place for security hooks, as long as it will
>> be placed next to the existing DAC checks.
>> It seems to me its simplicity of design is unignorable benefit.
> 
> In either design, you have to decide where to put the post-creation
> hook.  In your design, you ALSO need to decide where to put the
> pre-creation hook.  Deciding where to put the pre-creation hook may be
> simple, but it is not as simple as not having it at all.
> 
If the post-creation hook have two tasks (access control and fix-up
security labels) concurrently, things we need to consider and assess
is not equal to the case when we only fix-up security labels on the
post-creation hooks.
MVCC visibility is a typical example. Elsewhere, we need to check up
various things (such as completeness of the hook coverage, side-effects
of CommandCounterIncrement(), ...) without reliable guidelines.

I'm saying we can go through an easy way, as long as we design these
hooks according to a simple principle based on the existing features.

* pre-creation hooks (for access control) shall be put next to the existing DAC checks.
* post-creation hooks (for fix-up security label) shall be put next to the simple_heap_*(). Because OID and labels to
beassigned are already given, we don't need to consider such a complex things.
 

Even if we need to decide the place of two hooks, it seems to me
still simpler than security hooks from the scratch.

> A possibly legitimate reason to have a pre-creation hook is to prevent
> users from consuming more excessive system resources by repeatedly
> performing operations that SE-Linux will end up denying, but only
> after they're basically complete.
> 
We had similar discussion before when I tried to work on something
related to table-inheritance.
MergeAttributes() checks ownership of the parent table appeared in
the INHERITS() clause, then it immediately raises an error even if
one of them was not owned by the current user, because it allows
users to prevent accesses unprivileged tables, if we check these
ownership at once later.

I learned existing privilege-checks are located with their reasons.
So, it seems to me a good strategy to follow on existing design.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>