Re: SE-PostgreSQL/Lite Review - Mailing list pgsql-hackers

KaiGai Kohei escribio':
> Stephen Frost wrote:
>   
>> Josh,
>>
>> * Joshua Brindle (method@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