On Mon, 25 Oct 2010 21:45:23 -0400
Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> > One possible candidate is CheckMyDatabase() that checks ACL_CONNECT
> > permission for the required database prior to execution of all the
> > queries.
> > Currently, we don't have any security hook around here.
> > But, if we have "InvokeSecurityHook()" here, it will be able to
> > kill two birds with one stone. The 1st bird is getpeercon(3), and
> > the 2nd bird is permission check on the selected database.
>
> Yeah, that might be a possibility.
>
> >> This is closer to the mark, but mostly speculative, and not detailed
> >> enough to determine whether the proposed hook is properly located. ?It
> >> seems rather early to me: this is before we've sent the authentication
> >> packet to the client, so we couldn't, for example, log the success or
> >> failure of the authentication; we don't know whether it will succeed
> >> or fail.
> >>
> > Hmm. But the auth_failed() raises a fatal error, so we need to put
> > a hook before the invocation to log a case of authentication failed.
> >
> > | + ? if (ClientAuthentication_hook)
> > | + ? ? ? (*ClientAuthentication_hook)(port, status);
> > | +
> > | ? ? if (status == STATUS_OK)
> > | ? ? ? ? sendAuthRequest(port, AUTH_REQ_OK);
> > | ? ? else
> > | ? ? ? ? auth_failed(port, status);
> >
> > Or, perhaps, we should modify this if-block to ensure the hook being
> > called after sendAuthRequest() but before auth_failed().
>
> Oh. You know, I am realizing that I misread this patch. This hook is
> actually after authentication has been done; it's merely before we've
> told the client what happened. So maybe this is committable as-is,
> modulo some work on the comments.
>
OK, I'll re-submit my patch with a contrib module that utilizes
the authentication hook.
(Maybe, it just sleep a few seconds just after authentication failed.)
A hook on CheckMyDatabase() might be a candidate of this feature
and upcoming permission check.
But it will be a future work, is't it?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>