| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [v9.4] row level security |
| Date: | 2013-08-29 17:28:38 |
| Message-ID: | 9787.1377797318@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> That would close only one covert channel. Others were already pointed out
>> upthread, and I'll bet there are more ...
> Mind you, fundamentally this is no different from allowing INSERT
> permission on a table but denying SELECT, or denying SELECT on certain
> columns. In either case, covert channels for some data are available.
Certainly. But INSERT's purpose in life is not to prevent people from
inferring what data is in the table. What we have to ask here is whether
a "row level security" feature that doesn't deal with these real-world
attack techniques is worth having.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2013-08-29 17:42:14 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
| Previous Message | David Fetter | 2013-08-29 17:27:42 | Re: [v9.4] row level security |