KaiGai Kohei escribio': > 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, > I'm worried with the performance implications that have this patch on the core of the system. If you are aggregating more security layers, There is not a database degradation? I don't know how you attack these issues. Regards.
-- ------------------------------------- "TIP 4: No hagas 'kill -9' a postmaster" Ing. Marcos Lui's Orti'z Valmaseda PostgreSQL System DBA Centro de Tecnologi'as de Almacenamiento y Ana'lis de Datos (CENTALAD) Universidad de las Ciencias Informa'ticas(http://www.uci.cu) Linux User # 418229 http://www.postgresql-es.org http://www.postgresql.org http://www.planetpostgresql.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
