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

From Stephen Frost
Subject Re: [RFC] Security label support
Date
Msg-id 20100527202500.GN21875@tamriel.snowman.net
Whole thread Raw
In response to Re: [RFC] Security label support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [RFC] Security label support
List pgsql-hackers
* 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
labelassociated 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.

> 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.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Next
From: Bruce Momjian
Date:
Subject: Re: Synchronization levels in SR