Re: security hook on authorization

2010/8/19 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (2010/08/20 11:45), Robert Haas wrote:
>> 2010/8/19 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> I also plan to add a security hook on authorization time.
>>> It shall allow external security providers to set up credential of
>>> the authenticated clients.
>>>
>>> Please note that it is not intended to control authentication process.
>>> It is typically checked based on a pair of username and password.
>>> What I want to discuss is things after success of this authentication
>>> steps.
>>>
>>>  From viewpoint of SE-PostgreSQL, it uses getpeercon(3) which obtains
>>> a security label of the peer process, so it does not need to consider
>>> database username. But we can easily assume other security mechanism
>>> which assigns a certain label based on the authenticated database user
>>> such as Oracle Label Security.
>>>
>>> So, I think this hook should be also invoked on the code path of
>>> SET SESSION AUTHORIZATION, not only database login time, although
>>> SE-PostgreSQL ignores this case.
>>>
>>> So, I think SetSessionUserId() is a candidate to put this hook which is
>>> entirely called from both of the code path.
>>> This routine is to assign credential of the default database privilege
>>> mechanism, so it seems to me it is a good point where external security
>>> provider also assigns its credential of the authenticated database user.
>>
>> How is this different from what we rejected before?
>>
> It made clear the purpose of this hook.
>
> I also intended to use the previous hook for authorization purpose,
> but it was deployed just after initialize_acl() without no argument.
> It might be suitable for SE-PostgreSQL, because it does not depend on
> authenticated database user, but might be too specific.
>
> The new hook shall be invoked on two code paths (database login and
> SET SESSION AUTHORIZATION). It allows upcoming security module which
> may assign client's credential based on the database user to utilize
> this hook also.

I think our standard criteria for the inclusion of hooks is that you
must demonstrate that the hook can be used to do something interesting
that couldn't be done without the hook. So far I'm unconvinced.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company