Re: security hook on table creation

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, Alvaro Herrera <alvherre@commandprompt.com>, PgSQL-Hackers <pgsql-hackers@postgresql.org>, Joshua Brindle <method@manicmethod.com>, "David P. Quigley" <dpquigl@tycho.nsa.gov>
Date: 2010-10-12T14:09:09Z
Lists: pgsql-hackers
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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company