At this point I am so confused I don't have any response. ---------------------------------------------------------------------------
KaiGai Kohei wrote: > >> But SE-PostgreSQL does not need its table option to control > >> its availability per table granuality due to its security model. > >> > >> Database ACL is a kind of DAC. It allows resource owners to > >> set up its access rights. In other hand, SE-PostgreSQL is an > >> implementation of MAC. It does not allow owners to control its > >> access rights. This is the role of centralized security policy, > > > > It is fine if you require SECEXT to be on for SE-Linux, but the option > > must be available for non-SE-Linux so you can load dumps from either > > Postgres configuration, and /data is compatible with both versions. > > It is unclear for me why you thought this option is necessary to load > dumps generated by vanilla PostgreSQL? > I assumes the security column should be always available, so we don't > need to add a column when SE-PostgreSQL load a vanilla $PGDATA. > > >>> When SE-Linux is enabled, CREATE TABLE would issue an error if SECEXT > >>> was false. I can't think of a clean way to guarantee that existing > >>> tables have SECEXT though, which means we might need to have a missing > >>> 'security_context' column mean default SE-Linux permissions. > >> SE-PostgreSQL stores its security context on the security field of > >> HeapTupleHeader and set HEAP_HASSECURITY of t_infomask. > >> The security system column is always available, so it does not make > >> any matter. When no guest is available on PGACE, HEAP_HASSECURITY of > >> t_infomask is not set, so security field is not allocated and NULL > >> bitmask is not polluted. > > > > If you make an SE-Linux dump with security fields, how will that be > > loadable in a non-SE-Linux Postgres database? > > In this case, user should no dump his database with security field. > The patched pg_dump does not dump security field without > '--security-context' option. > > > We are also going to need ALTER TABLE to be able to add/remove these > > columns from tables, like OIDs. > > I don't agree. > The "security column" (not a "acl column") should be always exist. > In the vanilla binary, it simply returns NULL or empty string, so there is > no waste of storage consumption. > It is worthful when we run SE- binary with $PGDATA generated by vanilla one. > Any stored tuple does not have security field, but it gives DBAs a chance to > relabel them via the "security column". > > >> >> If we assume users set up Row-level ACLs for specific tables, per-table > >> >> option is meaningful for reduction of NULL-bitmap space in the tuple > >> >> without any NULL-values on general columns. > >> > > >> > Right. I was hoping there was a way to have HEAP_HASSECACL control if > >> > the value is present or not. > >> > > >> > I sure wish others were adding ideas to this discussion. > >> > >> I have a plan to add a new field (declared as "int2 relrowacl") into > >> pg_class to show what column stores its Row-level ACLs. > >> When we create a table with (ROWACL=TRUE), it implicitly add a column > >> declared as "security_acl aclitem[]", and its attribute number is > >> stored within the "pg_class.relrowacl". If it has positive value, > >> tuples within the table can have its individual ACLs. No-ACL is > >> represented via the NULL-bitmap. If it is zero, the table does not > >> have the "security_acl" column, and the row-level controls are simply > >> ignored. > > > > I am confused why we would want this instead of the way we do oids. > > It enables to implement the hardcoded row-acl more simple. > It allows to store variable length ACLs using existing mechanism, and > makes unnecessary to translate between ACLs and raw text representation. > > > Thanks, -- 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
