Simon Riggs wrote: > On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote: >> Tom Lane wrote: >>> KaiGai Kohei <[EMAIL PROTECTED]> writes: >>>> Bruce Momjian wrote: >>>>> I assume that could just be always enabled. >>>> It is not "always" enabled. When we build it with SE-PostgreSQL feature, >>>> rest of enhanced security features (includes the row-level ACL) are >>>> disabled automatically, as we discussed before. >>> It seems like a pretty awful idea to have enabling sepostgres take away >>> a feature that exists in the default build. >> Why? >> >> The PGACE security framework allows one or no enhanced security >> mechanism at most. It is quite natural that the default selection >> is overrided when an alternative option is chosen explicitly. > > I'm finding these discussions very confusing to follow, sorry about > that. > > We now have a parameter option that allows you to have row level > security in non-mandatory mode, which is good. But in order to get that > we need to build the server with a special configure option.
We need to distinguish a selection of enhanced security mechanism and options provided by the mechanism chosen. The PGACE security framework allows one or no enhanced security mechanism at most when it is built. Thus, we have to determine what mechanism to be activated. Currently, we have two enhanced security mechanism for v8.4. The one is SE-PostgreSQL, and the other is Row-level ACLs. SE-PostgreSQL is a MAC-based feature which provides column/row level granularity and collaboration with operating system. It provides two GUC parameter options as follows: - sepostgresql = (default|enforcing|permissive|disabled) - sepostgresql_row_level = (on|off) Row-level ACLs is a DAC-based feature which provides row level granularity and works independently from operating system security. It provides two table options as follows: - row_level_acl = (on|off) - default_row_acl = '<ACL text>' > My previous objective was to remove the need for a configure option, so > we can enable row-level security in the default distribution of > Postgres. Are we going to enable that option in all normal distros? If > yes, why is it a configure option (at all)? The purpose of configure options is to choose a enhanced security mechanism implemented on the PGACE security framework. It is unclear for me what means the "row-level security" in this context. Is it provided by SE-PostgreSQL? Row-level ACLs? We currently have no option to disable all the enhanced security mechanism, so one mechanism has to be choosen at least. Both of the two mechanisms being available now provide row-level granularity, so "row-level security" will be always enabled *in the result*. Please note that it can be provided by different security mechanism which is designed with independent security model. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
