> > > > > 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.
I formulated that sentence badly , sorry :-(
Replace with:
Since the security info is already normalized, one such idea would be:
> > 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.
>
> We already have this.
>
> The idea is that the security columns will hold an OID and the OID will
> point to a row in a table that contains the security rights/ACL for the
> column, with multiple rows using the same rights OID. If you change the
> rights on the column the code has to check the existing entries and add
> a new one if it doesn't already exist. This does add the problem of how
> to remove security rows that are no longer referenced.
Please reread with above correction,
and I'll also try a little differently:
Since a pg_security row already represents a combination of rights
within selinux, I do not really see why that cannot be extended to "a combination
of rowacl and selinux rights" or more general "one oid represents a unique
combination of rights within different subsystems" ?
A simplified example of pg_security:
oid rights
1 selinux:secret_read rowacl:ra,rb
2 selinux:unlabeled_t rowacl:ra,rb
3 selinux:secret_read rowacl:ra
Andreas