Stephen Frost wrote: > Josh, > > * Joshua Brindle (met...@manicmethod.com) wrote: >> Stephen Frost wrote: >>> I do think that, technically, there's no reason we couldn't allow for >>> multiple "only-more-restrictive" models to be enabled and built in a >>> single binary for systems which support it. As such, I would make those >>> just "#if defined()" rather than "#elif". Let it be decided at runtime >>> which are actually used, otherwise it becomes a much bigger problem for >>> packagers too. >> It isn't just a case of using #if and it magically working. You'd need a >> system to manage multiple labels on each object that can be addressed by >> different systems. So instead of having an object mapped only to >> "system_u:object_r:mydb_t:s15" you'd also have to have it mapped to, >> eg., "^" for Smack. > > I'm not sure I see that being a problem.. We're going to have > references in our object managers which make sense to us (eg: table > OIDs) and then a way of mapping those to some label (or possibly a set > of labels, as you describe). We might want to reconsider the catalog > structure a bit if we want to support more than one at a time, but I > don't see it as a huge problem to support more than one label existing > for a given object.
If we allow multiple security labels on a database object, we have to expand the structure of system catalog whenever a new security feature will come in. I think it against to the purpose of the framework. Even if we store them external relations to reference the object by OID, we have to provide multiple interface to import/export a security label for each enhanced securities. For example, it requires much complex patch to the pg_dump. My preference is all the enhanced securities shares a common facility to manage security label, a common statement support and a common backup/restore support. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
