|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: [v9.1] Add security hook on initialization of instance|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Robert Haas (robertmhaas(at)gmail(dot)com) 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.
Maybe so, but the proposed hook placement doesn't actually allow a
plugin module to be "involved" in the authorization --- we've already
decided the authorization is OK. All it can do there is some additional
initialization, which could equally well be done on first use (if any)
of the additional information.
There might be some value in letting a plugin actually have some control
over the authentication process, but I'm not sure offhand what a
reasonable hook design would be.
regards, tom lane
|Next Message||Robert Haas||2010-07-08 14:42:03||Re: [v9.1] Add security hook on initialization of instance|
|Previous Message||Tom Lane||2010-07-08 14:18:40||Re: patch: preload dictionary new version|