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
