Re: [RFC] Security label support - Mailing list pgsql-hackers

(2010/05/28 5:25), Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Stephen Frost<sfrost@snowman.net>  writes:
>>> Err, your question comes across to me like "if you added comments to
>>> pg_depend, you'd only be able to use a given comment X for one object?".
>>> Doesn't make alot of sense. :)
>>
>> Well, one of us is confused.  I thought the idea was that the same
>> security label would apply to many different objects.  If each object
>> has its own label, you're going to need an awfully large label cache
>> for performance to be sane.
> 
> It's certainly true that many objects could, and probably would in most
> situations, have the same label.  I feel like that could be true of
> comments as well.  We were just thinking about keeping it simple in the
> first go-round.  Going back to what I think was KaiGai's earlier
> question about which way to go:
> 
> #1: only have pg_description-like pg_seclabel
>      (objoid oid, classoid oid, objsubid integer, label text)
> 
> #2: have long-lived labels in pg_seclabels with (secoid oid, label text)
>      have label_oid in various system catalogs (pg_class, etc)
> 
> #3: have long-lived labels in pg_seclabels with (secoid oid, label text)
>      have mapping from each object to OID of label associated with it
>     (objoid oid, classoid oid, objsubid integer, secoid oid)
> 
> My inclination would generally be towards #2, to be honest, but I
> thought we wanted to avoid changing pg_namespace, pg_class and
> pg_attribute for this.
> 
Are you talking about a future development, aren't you?

I comment it for just a future development, not current efforts.

I plan the security-Id which points to an entry of pg_seclabel shall
be stored within padding area of HeapTupleHeader like what we are doing
to store object-Id.
The object-Id is stored only when HEAP_HASOID is set on t_infomask.
It does not damage to the existing schema of system catalog, and
allows to turn on/off the table's capability to store the security-Id.
Maybe, if we set up SELinux support, we need to run a special program
to initialize the database cluster just after initdb. It will turn on
the capability to store security-Id of the pg_class and so on.
Of course, we can apply same way between system catalogs and users'
tables.

>> OK, but the notion that you would try to remove "orphan" pg_labels
>> entries seems entirely wrongheaded to me.  The labels would be
>> long-lived objects.
> 
> OK, then we should really go with either #2 or #3 from above, and make
> sure that we add appropriate grammar to allow adding and removing of
> security labels.  Do we then throw an error if someone tries to put a
> label on an object that we don't already know of?  We certainly need to
> complain if someone tries to remove a label that is used by an object
> somewhere.  Typically, I'd expect the set of labels to be pretty well
> defined, but there will still be some amount of churn, and we'll need a
> way for people to determine what objects are still using certain labels.
> Not unlike how we deal with roles today already though.
> 
As Bruce suggested before, pg_seclabel should have relid field which
ensures the relation which references the security label entry.
It allows us to reclaim orphan security label with minimum locks.

In SE-PostgreSQL of Fedora, I provide a method to reclaim orphan labels:
 LOCK <target table> IN SHARE MODE;
 DELETE FROM pg_seclabel WHERE relid = <OID of target table> AND     secid NOT IN (SELECT tuple_to_secid(<target
table>)FROM ONLY <target table>);
 

During the reclaims, the <target table> is locked for writable accesses,
but we don't need to lock out whole of the database to detect orphan labels.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>