Zeugswetter Andreas OSB sIT wrote:
>
> > > > 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.
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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +