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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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