(2010/06/15 10:12), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>> (2010/06/15 9:22), Robert Haas wrote:
>>> 2010/6/14 KaiGai Kohei<kaigai@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.
>
The 'initialization hook' might be misleading.
During authentication steps, the backend raises an error and close
the connection immediately, if the backend could not identify the
client in the configured way.
Because I think security context is a part of identifiers of the user,
not only database user id, I proposed a hook on the initialization
stage. (Perhaps, it might be placed on just after ClientAuthentication?)
I can agree that we can implement the module with this idea,
but delayed getpeercon() seemed to me strange.
# Of course, it is reasonable if we discuss it later.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
