Re: [v9.2] SECURITY LABEL on shared database object

> On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)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 a common belief, TEXT is a variable length data type, so pg_shseclabel
need to have its toast table. However, I don't expect the label field get
represented as a reference to external pointer, because average length of
security context is about 40-60 bytes much less than the threshold to
launch toast_save_datum().
Do I need to remove these toast table & index?

> 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).
>
In SELinux, all we are doing in the authentication hook is to acquire
security label of the client, without referencing any catalogs.

I also plan to support permission checks on the selected database
in the future, however, I believe its hook should be placed in
CheckMyDatabase() according to the existing checks.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei(dot)kaigai(at)emea(dot)nec(dot)com>