> > > > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers