On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> FWIW, I am still of the opinion that we shouldn't have a hook here
>> anyway, because there is no reason to complain about lack of a
>> security context until the user performs an action which requires them
>> to have a security context.
>
> I don't agree with this, in general. It may be a difficult problem to
> solve though. From my perspective the above is similar to saying we
> don't need a pg_hba.conf or that we should open a database before
> checking the user's credentials. I'd like to give a security module the
> ability to be involved in the initial connection authorization, but we
> run into an issue there if that module then needs access to the catalog.
> Perhaps it doesn't, but it seems like it would, to use to make a
> decision.
Well, perhaps I'll revise my opinion here a bit. If we're actually
going to do something with the user's security context at connection
time, like validate that they have rights to connect to the database
they've selected, then it would make sense to have a hook somewhere in
the authentication process.
I think we have to assume that whatever actions a pluggable security
provider might take at authentication time are going to be based on
information from outside the database. It would be nice to have an
infrastructure that would support making an access control decision
based on data from within the database, but as of today any catalogs
consulted during authentication must be (a) shared and (b) nailed, and
there's certainly no provision for third-party modules to add shared
or nailed system tables (or even, ordinary system tables).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company