Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > KaiGai Kohei wrote:
> >>>> Please consider SELinux/SE-PostgreSQL requires various kind of objects
> >>>> (including database objects) to be labeled properly at the initial state.
> >>>> If it allows clients to turn on row-level security feature, it means many
> >>>> "unlabeled" tuples appear suddenly. In generally, these have to be labeled
> >>>> before the system get being available.
> >>> I was thinking more about people are using the SQL-level row
> >>> permissions. Are they going to want it for all tables for all
> >>> databases, or not at all?
> >> We don't have a reason why the SQL-level row permissions should be toggled
> >> in global only. It it designed based on DAC policy, so it is quite natural
> >> to be controled by owner of resources.
> >> (However, it is not implemented yet.)
> >
> > Yes, that was my question --- how will SQL-level row permissions be
> > controlled by the user.
>
> When the given tuple has no ACL, it applies the default behavior which
> allows anything for public. This behavior intends to keep compatible
> works compared to the vanilla PostgreSQL.
>
> We can have two state for "no ACLs". The first one is when tuples don't
> have fixed 4-bytes security attributes. It can be happen when PostgreSQL
> with SQL-level row-permissions mount compatible database files created
> by vanilla PostgreSQL. The other is the fixed 4-byte security attribute
> indicates an entry of "no ACLs". It seems unnecessary consumption, but
> we cannot determine whether the user tries to set ACLs when heap_form_tuple().
>
> One considerable solution is to add an RowACL specific table option to
> disable row-level ACLs whole of the tables. It can be suitable for security
> design because the option is provided by the resource owner.
>
> For example:
>
> CRATE TABLE t (
> a int,
> b text
> ) WITH (row_acl=disable);
>
> If the reloptions contains an information to determine whether a new tuple
> need the security field, or not, we can reflect it at heap_form_tuple().

What I am saying is for the default compile, SQL-level ACLs should be
possible because, since the ACL field has optional storage, there is no
downside to have it be available by default.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +