Re: [v9.4] row level security
От | Kohei KaiGai |
---|---|
Тема | Re: [v9.4] row level security |
Дата | |
Msg-id | CADyhKSUtkyx5pqOUJZPr0XeO8987GCHb_8aQFfUZ2UKHx8n69A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.4] row level security (Marc Munro <marc@bloodnok.com>) |
Список | pgsql-hackers |
Because of CF-2nd end, it was moved to the next commit-fest. In my personal opinion, it probably needs a few groundwork to get RLS commitable, prior to RLS itself. One is a correct handling towards the scenario that Korotkov pointed out. (How was it concluded?) I think it is a problem we can fix with reasonable way. Likely, solution is to prohibit to show number of rows being filtered if plan node is underlying a sub- query with security-barrier. One other stuff I'm concerned about is, existing implementation assumes a certain rtable entry performs as a source relation, also result relation in same time on DELETE and UPDATE. We usually scan a regular relation to fetch ctid of the tuples to be modified, then ModifyTable deletes or updates the tuple being identified. Here has been no matter for long period, even if same rtable entry is used to point out a relation to be scanned and to be modified. It however makes RLS implementation complicated, because this feature tries to replace a rtable entry to relation with row-level security policy by a simple sub-query with security-barrier attribute. Our implementation does not assume a sub-query performs as a result relation, so I had to have some ad-hoc coding, like adjustment on varno/varattno of Var objects, to avoid problem. I think, solution is to separate a rtable entry of result-relation from rtable entry to be scanned. It makes easier to implement RLS feature because all we need to do is just replacement of rtable entry for scanning stage, and no need to care about ModifyTable operations towards sub-query. Is it a right direction to go? Thanks, 2013/10/10 Marc Munro <marc@bloodnok.com>: > On Wed, 2013-09-04 at 14:35 +0000, Robert Haas wrote: >> >> On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > I think it's entirely sensible to question whether we should reject >> (not >> > "hold up") RLS if it has major covert-channel problems. >> >> We've already had this argument before, about the security_barrier > [ . . . ] > > Sorry for following up on this so late, I have just been trying to catch > up with the mailing lists. > > I am the developer of Veil, which this thread mentioned a number of > times. I wanted to state/confirm a number of things: > > Veil is not up to date wrt Postgres versions. I didn't release a new > version for 9.2, and when no-one complained I figured no-one other than > me was using it. I'll happily update it if anyone wants it. > > Veil makes no attempt to avoid covert channels. It can't. > > Veil is a low-level toolset designed for optimising queries about > privileges. It allows you to build RLS with reasonable performance, but > it is not in itself a solution for RLS. > > I wish the Postgres RLS project well and look forward to its release in > Postgres 9.4. > > __ > Marc > > -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: