(2010/08/22 0:20), Robert Haas wrote:
On Aug 20, 2010, at 8:27 PM, KaiGai Kohei<kai...@kaigai.gr.jp>  wrote:
(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Kohei<kai...@ak.jp.nec.com>:
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.

We cannot handle an error of labeled networking (getpeercon(3)),
if we don't have any hook during client authorization stage.

If and when a connection came from a host but we don't accept the
delivered security label, or labeled networking is misconfigured,
getpeercon(3) returns NULL. In this case, server cannot identify
what label should be applied on the client, then, we should
disconnect this connection due to the error on database login,
not any access control decision.

In similar case, psm_selinux.so disconnect the connection when
it cannot identify what security label shall be assigned on the
session, due to some reasons such as misconfigurations.

Without any hooks at authorization stage (but it might be different
place from this patch, of course), we need to delay the error
handling by the time when SE-PostgreSQL module is invoked at first.
But it is already connection established and user sends a query.
It seems to me quite strange behavior.

You mentioned that before.  I'm not totally sure I buy it, and I think
 there are other applications that might benefit from a hook in this area.
 We need to think about trying to do this in a way that is as general as
 possible.  So I'd like to see some analysis of other possible applications.

Yes, I also think this kind of authorization hook should benefit other
applications, not only label based mac features.

For example, something like 'last' command in operations system which
records username and login-time. Stephen mentioned pam_tally that locks
down certain accounts who failed authentication too much.
Perhaps, PAM modules in operating system give us some hints about other
possible applications.

KaiGai Kohei <kai...@kaigai.gr.jp>

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to