(2010/10/12 20:59), Robert Haas wrote:
2010/10/11 KaiGai Kohei<kai...@ak.jp.nec.com>:
It enables us to put security hooks independent from MVCC visibility of
the new database object. If we pay attention for visibility of new database
object, it seems to me amount of things to understand and maintain will be
increased, although MVCC visibility is fundamentally unrelated stuff from
viewpoint of the access control.
In the idea of two hooks, the prep-creation hook shall be invoked in same
visibility of existing permission checks, and the post-creation hook shall
be invoked in same visibility of simple_heap_* operations.
I think it enables to reduce amount of things to understand and maintain,
because the scope we should pay attention become small, if we can put
security hooks independent from MVCC visibility.
Perhaps, the problem may be intangible, but I don't think it is fair
enough if we have to pay attention about MVCC visibility of plugin
modules whenever we try to apply a patch around creation hooks.
This may be nothing more than a matter of opinion, but it seems to me
that what you're proposing makes this vastly more complicated for no
particular benefit. Instead of having one hook that can cover a wide
variety of use cases, you're going to need individual hooks for each
object type plus the ability to pass data between them.
In the broad outline, I also agree with one main security which can
cover most of use cases. However, the only difference is that I'm
saying we should handle prep-creation case as exception of the main
hook.
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.
And the point
of this, apparently, is so that you can avoid using the standard
syscache functions that the entire backend uses for retrieving
information about objects and instead extract it in some other way;
and/or avoid having to deal with the MVCC properties of which the rest
of the backend must be aware.
It just means it is not impossible...
However, it requires the plugin modules need to know everything;
such as what is visible/invisible. It seems to me too closely-
coupled interface.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
