Prev: pg_dump(all) --quote-all-identifiers
Next: Command Prompt 8.4.4 PRMs compiled with debug/assertenabled
From: KaiGai Kohei on 15 Jun 2010 03:08
(2010/06/15 12:47), KaiGai Kohei wrote:
> (2010/06/15 12:28), Tom Lane wrote:
>> KaiGai Kohei<kaigai(a)ak.jp.nec.com> writes:
>>>>>> The attached patch tries to add one more security hook on the
>>>>>> initialization of PostgreSQL instance (InitPostgres()).
>>
>>>> Yeah, but so what? Stephen's point is still valid.
>>
>>> 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.
>>
>> InitPostgres is called by a number of process types that don't *have*
>> clients. I concur with the other opinions that this hook is badly
>> thought out.
>>
> I intended to skip it when InitPostgres() is called without clients.
>
> For example, the hook might be better to put on PerformAuthentication()
> for more clarification of the purpose.
>

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.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
From: Robert Haas on 15 Jun 2010 10:24
On Tue, Jun 15, 2010 at 8:37 AM, Stephen Frost <sfrost(a)snowman.net> wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(a)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.

+1.

> 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.

+2.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 8 Jul 2010 09:14
2010/6/16 KaiGai Kohei <kaigai(a)ak.jp.nec.com>:
> OK, fair enough. Please wait for a few days.
> I'll introduce the proof-of-concept module until this week.

I think we have decided not to pursue this, at least for now. If that
is the case, the CommitFest entry should be updated to Returned with
Feedback.

https://commitfest.postgresql.org/action/patch_view?id=323

FWIW, I am still of the opinion that we shouldn't have a hook here
anyway, because there is no reason to complain about lack of a
security context until the user performs an action which requires them
to have a security context.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 8 Jul 2010 10:40
Stephen Frost <sfrost(a)snowman.net> writes:
> * Robert Haas (robertmhaas(a)gmail.com) wrote:
>> FWIW, I am still of the opinion that we shouldn't have a hook here
>> anyway, because there is no reason to complain about lack of a
>> security context until the user performs an action which requires them
>> to have a security context.

> I don't agree with this, in general. It may be a difficult problem to
> solve though. From my perspective the above is similar to saying we
> don't need a pg_hba.conf or that we should open a database before
> checking the user's credentials. I'd like to give a security module the
> ability to be involved in the initial connection authorization, but we
> run into an issue there if that module then needs access to the catalog.

Maybe so, but the proposed hook placement doesn't actually allow a
plugin module to be "involved" in the authorization --- we've already
decided the authorization is OK. All it can do there is some additional
initialization, which could equally well be done on first use (if any)
of the additional information.

There might be some value in letting a plugin actually have some control
over the authentication process, but I'm not sure offhand what a
reasonable hook design would be.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 8 Jul 2010 10:42
On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost <sfrost(a)snowman.net> wrote:
>> FWIW, I am still of the opinion that we shouldn't have a hook here
>> anyway, because there is no reason to complain about lack of a
>> security context until the user performs an action which requires them
>> to have a security context.
>
> I don't agree with this, in general. �It may be a difficult problem to
> solve though. �From my perspective the above is similar to saying we
> don't need a pg_hba.conf or that we should open a database before
> checking the user's credentials. �I'd like to give a security module the
> ability to be involved in the initial connection authorization, but we
> run into an issue there if that module then needs access to the catalog.
> Perhaps it doesn't, but it seems like it would, to use to make a
> decision.

Well, perhaps I'll revise my opinion here a bit. If we're actually
going to do something with the user's security context at connection
time, like validate that they have rights to connect to the database
they've selected, then it would make sense to have a hook somewhere in
the authentication process.

I think we have to assume that whatever actions a pluggable security
provider might take at authentication time are going to be based on
information from outside the database. It would be nice to have an
infrastructure that would support making an access control decision
based on data from within the database, but as of today any catalogs
consulted during authentication must be (a) shared and (b) nailed, and
there's certainly no provision for third-party modules to add shared
or nailed system tables (or even, ordinary system tables).

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: pg_dump(all) --quote-all-identifiers
Next: Command Prompt 8.4.4 PRMs compiled with debug/assertenabled