On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
