2010/6/14 KaiGai Kohei <kai...@ak.jp.nec.com>: > (2010/06/15 9:22), Robert Haas wrote: >> 2010/6/14 KaiGai Kohei<kai...@ak.jp.nec.com>: >>> On the hook, I'd like to obtain security context of the client process >>> which connected to the PostgreSQL instance. It is not available at the >>> _PG_init() phase, because clients don't connect yet. >> >> Can't you just call getpeercon() the first time you need the context >> and cache it in a backend-local variable? Then you don't need a hook >> at all. >> > I've tried to implement my earlier version in this idea. > As long as getpeercon() performs correctly, it will work well. > But, if it returns an error due to the system configuration, > the security module cannot continue to make access control > decision anymore, although client can open the connection already. > > I think this kind of initialization should be also done at > the initialization of backend, then it disconnect immediately > if something troubled.
I think if getpeercon() fails you can just throw ERROR or FATAL at that point. Until the user does something that requires a valid security context, there's no reason to terminate the session if they don't have one. -- 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
