(2010/05/28 5:25), Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost<sfr...@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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
