From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Joshua Brindle <method(at)manicmethod(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SE-PostgreSQL/Lite Review |
Date: | 2009-12-12 00:46:30 |
Message-ID: | 4B22E7E6.900@kaigai.gr.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> Josh,
>
> * Joshua Brindle (method(at)manicmethod(dot)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 <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-12 00:52:27 | Re: Adding support for SE-Linux security |
Previous Message | KaiGai Kohei | 2009-12-12 00:32:01 | Re: SE-PostgreSQL/Lite Review |