Re: [v9.1] Add security hook on initialization of instance - Mailing list pgsql-hackers

(2010/06/15 21:37), Stephen Frost wrote:
> KaiGai,
> 
> * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
>> In the attached patch, the security hook was moved to ClientAuthentication()
>> from InitPostgres(), for more clarification of the purpose.
>> What I want to do is to assign additional properties to identify the client
>> (such as security label) for each authenticated session.
>>
>> Its purpose is similar to "session" module of PAM in operating system.
>> It allows to assign additional session properties more than user-id.
> 
> That's all fine- but let's work within the confines of the *existing*
> hook that's been discussed to get something working first before we go
> adding hooks in other places.  I think it's important that we put
> together at least a proof of concept that an SELinux module or other
> external auth module can sensible use the DML hook.
> 
Yes, I'd like to introduce the reason and purpose of the hook.

At first, please assume any external security modules should be loaded
as shared preload libraries, because 'local_preload_libraries' setting
can be overwritten using connection string.
So, _PG_init() shall be invoked at the starting-up of the postmaster
daemon process at once, not per connection.

On the other hand, a security feature have to identify the client and
assign an appropriate set of privileges on the session prior to it being
available for users.
E,g. The default PG security assigns a certain database user-id on
the current session, then it will be used for access control decision.
In a similar way, an external security also wants a chance to identify,
authenticate and authorize the client. (SELinux uses getpeercon() to
obtain security label of the peer process, and applies it as privilege
of the current session.)

However, here is no hooks available for the purpose. In this case,
_PG_init() is not called for each connections, because the module is
a shared preload library, so we have to call getpeercon() in another
point.

One idea is, as Robert suggested, that we can invoke getpeercon() at
the first call of SELinux module and store it on the local variable.
It will work well as long as getpeercon() does not cause an error.

Robert pointed out we can always raise ERROR or FATAL using ereport(),
if it is troubled.
However, it seems to me a trouble of getpeercon() is fundamentally
an error within the step of client authentication.
In the case of database user-id, it immediately raises an error, and
close the connection. I think we should follow the manner of similar
features, so I proposed the new security hook at the authentication.

Thanks,

> After that, we can discuss what other hooks are needed.  KaiGai, please,
> before sending in patches of any kind, propose at a high-level what the
> problem is and what the security module needs in general terms.  If you
> have a recommendation, that's fine, but let's talk about it before
> implementing anything.
> 
>     Thanks,
> 
>         Stephen


-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>