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: