Re: [v9.2] SECURITY LABEL on shared database object - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] SECURITY LABEL on shared database object
Date
Msg-id CA+TgmoZO4Q6xSEhimL+2k2C18-PsZ3-H7fp39DuNdkm3OQNq6w@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] SECURITY LABEL on shared database object  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [v9.2] SECURITY LABEL on shared database object
List pgsql-hackers
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
>
>> Hmm, OK.  I guess what I'm not sure about is - how much should we
>> worry about the fact that this creates several more shared (and
>> therefore nailed?) system catalogs?  Anyone have an opinion on that?
>
> "Several"?  That would worry me, given that we currently have a small
> number (eight currently).  If it's just one more, I don't think it's
> such a big deal.  I'm not sure what you mean by nailed though -- I mean,
> for example pg_shdescription is shared but not nailed in the rd_isnailed
> sense of the word, AFAICS.

Well, right now the patch has pg_shseclabel, and its index, plus a
toast table and a toast index.  Not sure why we want/need the toast
table & index there, but the patch has 'em as of now.

As for whether it needs to be nailed, I'm not sure I understand what
the rules are there.  I *think* the rule is that anything that might
need to be consulted before choosing a database must be nailed.  If
that's right, we might be able to get by without nailing it, as long
as the label isn't needed during authentication (or its use can be
postponed until after we've connected to a database).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Pavel Golub
Date:
Subject: COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Next
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Move Trigger and TriggerDesc structs out of rel.h into a new rel