On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
