Re: security label support, revised - Mailing list pgsql-hackers

From Robert Haas
Subject Re: security label support, revised
Date
Msg-id AANLkTimTTcpDWvJP2ywwO14kHRqSL--_Px66gs4M1TwR@mail.gmail.com
Whole thread Raw
In response to Re: security label support, revised  (Stephen Frost <sfrost@snowman.net>)
Responses Re: security label support, revised
List pgsql-hackers
On Thu, Sep 23, 2010 at 10:21 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> Most of the contents of the new documentation section on external
>> security providers seemed irrelevant to me, which I guess I can only
>> blame myself for since I was the one who asked for that section to be
>> created, and I didn't specify what it should contain all that well.  I
>> took a try at rewriting it to be more on-topic, but it didn't amount
>> to much so I ended up just ripping that part out completely.
>
> Do we have a place where we actually document hooks today..?  Seems like
> we should and that'd be a good place to put the few necessary comments
> regarding these.

We do not.  Whether or not we should, I'm not sure.

>> There are a few other problems.  First, there's no psql support of any
>> kind.  Now, this is kind of a corner-case feature: so maybe we don't
>> really need it.  And as I mentioned on another thread, there aren't a
>> lot of good letters left for backslash-d commands.
>
> One thought would be to add it to \dp or have a \dp+.

That only works for table-ish things, though.

>> So I'd be just as
>> happy to add a system view along the lines I previously proposed for
>> comments and call it good.
>
> I think that regardless of psql and \d, we should have a sensible system
> view for it.

That's fine with me.  The one I wrote for comments can probably be
adapted pretty easily.

>> Second, there are no
>> regression tests.  It's a bit tricky to think about how to crack that
>> nut because this feature is somewhat unusual in that it can't be used
>> without loading an appropriate loadable module.  I'm wondering if we
>> can ship a "dummy_seclabel" contrib module that can be loaded during
>> the regression test run and then run various tests using that, but I'm
>> not quite sure what the best way to set that up is.  SECURITY LABEL is
>> a core feature, so it would be nice to test it in the core regression
>> tests...  but maybe that's too complicated to get working, and we
>> should just test it from the contrib module.
>
> The first set of regression tests could simply run the SECURITY LABEL
> commands and then check the results in the catalog.  If some kind of
> psql support is included, it could test that also.  That doesn't check
> that the hooks are called at the right time and with the right data, so
> I agree with the suggestion to have dummy contrib modules (or something)
> to do that generically for all our hooks, but I don't think we've got
> anything like that today..?  If we do, then we should model it off
> whatever's there now.  Perhaps we can look at how to do it
> comprehensively for all hooks..

The point is that SECURITY LABEL, as coded, will fail utterly unless
there is a label provider loaded.  So you can't actually run it and
check the results in the catalog without loading a contrib module.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Why is time with timezone 12 bytes?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Configuring synchronous replication