On Thu, Sep 23, 2010 at 2:06 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> 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.
>
> Urgh, yes, point. Well, we could test that it errors out correctly. :)
Indeed.
> Another thought might be to allow the "check if a module is loaded
> before doing things" to be a postgresql.conf option that is disabled in
> the regression testing.. If you can modify postgresql.conf you can
> remove the module anyway..
That might work, although I'm not sure whether it's any easier that
getting a contrib module to run during the regression tests. I think
we're testing LOAD in there already somewhere, so...
> Interesting question as to if we should
> auto-fail queries against objects which have labels when no security
> module is loaded. Have we discussed that yet?
My feeling is that we should do what the existing code does, namely,
bounce the request immediately if the relevant label provider can't be
found. It isn't as if people can't modify the labels anyway in that
case, by messing with pg_seclabel by hand, but I don't really see the
need to spend extra code trying to make this work sensibly when I'm
not sure there's any real sensible behavior. I think that people who
write these modules will need to include a mechanism to disable
checking, hedged about with some appropriate protections. Isn't that
what SE-Linux permissive mode is for? (And you could possibly have a
similar concept within the module, just local to PG, driven off a GUC;
of course the assign_hook can ask SE-Linux whether it's OK to enable
PG-only permissive mode.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company