Robert Haas wrote:
Can you *do* the row-level permission?
I don't think there's any consensus on a design.
Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2
Getting consensus on a design seems to actually be one of the harder
aspects of PostgreSQL development. The pattern seems to be:
1. Someone submits a patch. By definition, the patch embodies some
particular design.
2. One or more members of core express concerns about the design
embodied in the patch.
3. If the concerns are fairly specific and not mutually contradictory,
the submitter revises the patch accordingly and it gets committed
(hopefully without having to discard too much of their previous work).
4. If the concerns are fairly vague and open-ended, or if they
contract each other, the patch hovers in limbo for eternity.
I'm not sure what the solution to this problem is. The fact that a
member of core does not like a particular design for feature X does
not oblige that person to produce a better one, but it's pretty tough
to proceed without it.
Yes, I have had similar experiences in Linux kernel development for
several years.
The amount of time to get consensus is one of the reason why I want
to move the SQL based row-level security to v8.5 development cycle.
In the case of SE-PostgreSQL, two members of core expressed concerns:
- Peter Eisentraut expressed concern about implementing row-level
security via SE-PostgreSQL without first implementing some sort of
SQL-based row-level security. KaiGai expressed willingness to
implement that, but we still don't have a design, so I assume KaiGai
is going to implement... something... and hope that it turns out to be
acceptable.
Its conclusion is actually not clear for me.
The proposed SQL based row-level security assumes what he pointed out
is right, but I don't know the reason why it should be placed prior.
I guess he intend to share the code for row-level security, thus it
should be implemented prior to the OS specific feature. But most of
SE-PostgreSQL code is separated from core implementation and invoked
via security hooks, so it is unsuitable to share code with other
facilities.
In my preference, I want to pay my efforts for OS-independent row-level
security in the v8.5 cycle with enough days, and want to concentrate for
SE-PostgreSQL in the v8.4 cycle, as I mentioned before.
But I will do, if it is unacceptable.
- Tom Lane expressed concerns about covert channels to which KaiGai
responded, AIUI, that the patch was pretty useful even without
addressing that issue, but if Tom isn't willing to see the patch
committed otherwise, then KaiGai has to decide between giving up and
attempting to implement some form of polyinstantiation - which will
not be easy, and which is far from guaranteed to be accepted if he
does develop it.
Its conclusion it not clear.
I think the polyinstantiation is too much requirements, as prior major
commercial RDBMS with row-level security (like Oracle Label Security)
does not care about such kind of covert channels.
It is quite natural to describe such kind of limitation/specification
on the documentation explicitly to help end-user's decision.
In both cases, the lack of a clear roadmap means that a dedicated
developer is potentially putting in a lot of time and effort
developing what may end up being a complete dead-end.
I believe such a situation will help nobody get happy.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
