Re: SE-PgSQL patch review

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

In response to

Browse pgsql-hackers by date

  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