On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Not sure I understand you. You suggested it was a valid use case for a > user to have only INSERT privilege and wish to bypass security checks. > I agreed and suggested it could be special-cased.
That's not really what I intended to suggest. I view checking an inserted tuple and checking the new version of an updated tuple as of a piece. I would think we would check against the RLS quals in either both of those situations or neither, not one without the other. > * "Applies to all commands" should not be implemented via triggers. > Complex, slow, unacceptable thing to force upon users. Doing that begs > the question of why we would have the feature at all, since we already > have triggers and barrier views. I agree that it is questionable whether we need this feature given that we already have security barrier views. I don't agree that performing security checks via triggers is unacceptably slow or complex. Rather, I would say it is flexible and can meet a variety of needs, unlike this feature, which imposes much tighter constraints on what you can and cannot check and in which situations. > * the default for row security should be "applies to all commands". > Anything else may be useful in some cases, but is surprising to users > and requires careful thought to determine if it is appropriate. I (and several other people, it seems) do not agree. > * How to handle asymmetric row security policies? KaiGai has already > begun discussing problems caused by a security policy that differs > between reads/writes, on his latest patch post. That needs further > analysis to check that it actually makes sense to allow it, since it > is more complex. It would be better to fully analyse that situation > and post solutions, rather than simply argue its OK. Kevin has made > good arguments to show there could be value in such a setup; nobody > has talked about banning it, but we do need analysis, suggested > syntax/mechanisms and extensive documentation to explain it etc. Frankly, in view of your comments above, I am starting to rethink whether we want this at all. I mean, if you've got security barrier views, you can check the data being read. If you've got triggers, you can check the data being written. So what's left? There's something notationally appealing about being able to apply a security policy to a table rather than creating a separate view and telling people to use the view in lieu of the table, but how much is that notational convenience worth? It has some value from the standpoint of compatibility with other database products ... but probably not a whole lot, since all the syntax we're inventing here is PostgreSQL-specific anyway. Your proposal to check both tuples read and tuples written might add some value ... but unless there's an as-yet-undemonstrated performance benefit, it is again mostly a notational benefit. -- 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
