Prev: pg_dump(all) --quote-all-identifiers
Next: Command Prompt 8.4.4 PRMs compiled with debug/assertenabled
From: KaiGai Kohei on 14 Jun 2010 20:41
(2010/06/15 9:22), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei<kaigai(a)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.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
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 14 Jun 2010 21:12
2010/6/14 KaiGai Kohei <kaigai(a)ak.jp.nec.com>:
> (2010/06/15 9:22), Robert Haas wrote:
>> 2010/6/14 KaiGai Kohei<kaigai(a)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.

--
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: KaiGai Kohei on 14 Jun 2010 22:26
(2010/06/15 10:12), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei<kaigai(a)ak.jp.nec.com>:
>> (2010/06/15 9:22), Robert Haas wrote:
>>> 2010/6/14 KaiGai Kohei<kaigai(a)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(a)ak.jp.nec.com>

--
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 14 Jun 2010 23:28
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.

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: KaiGai Kohei on 14 Jun 2010 23:47
(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.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

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