(2009/12/14 20:48), Robert Haas wrote:
2009/12/14 KaiGai Kohei<kai...@ak.jp.nec.com>:
Robert Haas wrote:
2009/12/13 KaiGai Kohei<kai...@ak.jp.nec.com>:
Just to name a few really obvious problems (I only looked at the
01-database patch):
1. We have been talking for several days about the need to make the
initial patch in this area strictly a code cleanup patch. Is this
cleaner than the code that it is replacing? Is it even making an
attempt to conform to that mandate?
Even if it is unclear whether the current form is more clear than the
current inlined pg_xxx_aclcheck() form, or not, it will obviously
provide a set of common entry points for upcoming enhanced security
providers.
Eventually, it is more clear than enumeration of #ifdef ... #endif
blocks for SELinux, Smack, Solaris-TX and others.
Right, but it will also not get committed. :-(
The framework will be necessary to get them committed.
Which is an egg, and which is a chicken? :-(
We've been around that path a few times, but that's not my point here.
Doing the framework first makes a lot of sense; the problem is that
we just had a design discussion regarding that framework and you've
chosen to do something other than what was discussed. Did you not
read that discussion? Did you not understand it?
Please point out, if my understanding is incorrect from the discussion
in a few days.
* As a draft of the discussion, I have to split out the access control
reworks patch in the 2nd CF per object classes.
* This framework supports only the default PG privileges at the moment.
* The way to host enhanced security providers are not decided.
(Maybe #ifdef ... #endif block, Maybe function pointer)
* It is not decided how many security labels are assigned on a database
object. (Maybe 1:1, Maybe 1:n)
I don't intend to go to something undecided, but, might understand
something incorrectly or not be able to follow the discussion enough.
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
