> > > Ah, that is a good point, that if we have "security column" which is
> > > usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think "WITH SECURITY_CONTEXT"
is needed.
> I sure wish others were adding ideas to this discussion.
One such idea would be, that the security info is already normalized.
pg_security has one row for each security_context. It is my understanding, that
such a context row may already be a combination of "rights". Thus adding an extra column
per subsystem to the user tables may not be required.
You could have all info for each security subsystem in the pg_security table.
This can eighter be done by having one row in pg_security per
subsystem type and oid, or by having a separate column in pg_security per subsystem.
The imho difficult part is, that currently selecting "security_context" defaults to mapping the
oid to the text representation for selinux. Concern has already been voiced in this regard.
Maybe this is another reason to not do automatic mapping, but require a specified conversion
for text output.
Or is the column name "security_context" and representation a standard ?
This is just an idea, since I do not really think actually using more than one
security subsystem in parallel will be common.
Andreas
