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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
