From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PgSQL patch review |
Date: | 2009-11-25 14:05:44 |
Message-ID: | 603c8f070911250605n317fa94eo97331a7ddc9f9538@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/11/24 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> BTW, I plan the following steps for the row-level security.
> | * A facility to put "security label OID" within the tuple header.
> | * System column support to print out the security context.
> | (This system column shall be writable to relabel)
> | * Pure-SQL row-level security checks, something like Oracle Private
> | Database which allows user defined access control decision function.
> | * SELinux aware row-level checks on the virtual private database stuff.
> V It can be implemented as one of the decision making functions.
I think we're getting ahead of ourselves talking about row-level
security at this point, but FWIW I have a lot of concerns about how
the previous version of this feature was designed. In particular, I
think we should set up row-level security in a way that (1) allows it
to be used for purposes other than SE-Linux and (2) allows
row-filtering to take advantage of indices. If I have a table with a
million rows, but only rights to see 100 of them, the system
administrator should be able to define an index that will allow the
100 I can see to be fetched via a bitmap-index scan rather than a
seq-scan with a probe for every row.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-11-25 14:14:57 | Re: Partitioning option for COPY |
Previous Message | Robert Haas | 2009-11-25 14:02:05 | Re: operator exclusion constraints |