| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, bogdan(at)omnidatagrup(dot)ro, David Fetter <david(at)fetter(dot)org>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SE-PostgreSQL and row level security |
| Date: | 2009-02-16 14:55:38 |
| Message-ID: | 16274.1234796138@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> One thing I keep missing in this discussion: the term "row-level
> security" in the above senstence in not the important part. Right now
> you can revoke SELECT permission on a table with a foreign key and it
> will still prevent UPDATEs and DELETEs of the primary key, allowing
> users to infer the existance of an invisible FK.
> This is the same "covert channel", so why is it a problem for
> SE-Postgres and not for normal Postgres?
The reason it's a problem for SE-Postgres is that the entire row-level
security feature is advertised on the premise that it allows you to
hide the existence of data; a claim not made by regular SQL. If the
feature doesn't do what it's claimed to do then it's fair to ask why
have it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-02-16 14:58:05 | Re: SE-PostgreSQL and row level security |
| Previous Message | Tom Lane | 2009-02-16 14:53:51 | Re: SE-PostgreSQL and row level security |