Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Date
Msg-id 1226680591.27904.613.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
List pgsql-hackers
On Sat, 2008-11-15 at 00:58 +0900, KaiGai Kohei wrote:

> Sorry, it seems to me you misunderstand something.

Yep, seems so. Thank goodness for that. Thanks for putting me straight.

> > I would also like to see the feature part of normal Postgres, rather
> > than as a compile time option. The per-row overhead would then be
> > optional, just as WITH OIDS is optional. This would allow many
> > applications to take advantage of row level security, without the need
> > for switching to a different executable and without the need to enable
> > it for every table. For high security applications, default_row_security
> > = on would obviously be a requirement. With a single executable on all
> > distros we will have more robust software and it will be easier to
> > configure and use.
> 
> An issue is who can enable or disable the row-level security option.
> If the owner of table can do it discretionary, we don't call it a
> "mandatory" access control feature.

It seems fairly easy to do that with a GUC, or at least an option on
CREATE DATABASE, with no equivalent ALTER DATABASE option. Once created
with security, a table would not be able to turn off security. So nobody
would be able to turn off security for existing data.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sometimes pg_dump generates dump which is not restorable
Next
From: Michael Meskes
Date:
Subject: Re: gram.y => preproc.y