On Mon, 25 Oct 2010 21:45:23 -0400 Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
