On 20 December 2012 19:42, Stephen Frost <sfrost@snowman.net> wrote:
> Kevin, all,
>
> * Kevin Grittner (kgrittn@mail.com) wrote:
>> The more secure behavior is to allow entry of data which will not
>> be visible by the person doing the entry.
>
> wrt this- I'm inclined to agree with Kevin. It's certainly common in
> certain environments that you can write to a higher level than you can
> read from. Granting those writers access to read the data later would
> be... difficult.
>
> What we're really arguing about here, afaict, is what the default should
> be. In line with Kevin's comments and Tom's reading of the spec (along
> with my own experience in these environments), I'd argue for the default
> to allow writing rows you're not allowed to read.
>
> It would certainly be ideal if we could support both options, on a
> per-relation basis, when we release the overall feature. It doesn't
> "feel" like it'd be a lot of work to do that, but I've not been able to
> follow this discussion up til now. Thankfully, I'm hopeful that I'm
> going to have more time now to keep up with PG. :)
It is certainly possible to deliver a row security feature that covers
all the cases discussed in 9.3. I want that.
1. The case of "row security applies to all commands" is simple to
implement and document, since it presents no anomalies.
2. As KaiGai has explained, there are significant anomalies in the
behaviour of "row security applies only to reads". Those anomalies
need to be analysed carefully. They also need to be explained to the
user in documentation.
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way. If people genuinely believe case (2) is worth pursuing,
additional work and input is needed so that KaiGai can make changes in
time for the 9.3 deadline. Please read what KaiGai has said and
respond. Since there are so many people reading this thread and
wanting (2), that seems reasonable to expect.
What I have proposed is that I work on the review for case (1) and
then if we solve (2) that can go in also. I don't think its reasonable
to reject the whole feature because of unresolved difficulties around
one use case, which is what will happen if this is seen as merely a
debate about defaults.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services