Prev: pg_dump(all) --quote-all-identifiers
Next: Command Prompt 8.4.4 PRMs compiled with debug/assertenabled
From: Stephen Frost on 14 Jun 2010 07:01
* KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
> The attached patch tries to add one more security hook on the
> initialization of PostgreSQL instance (InitPostgres()).
>
> It gives the external security module a chance to initialize itself,
> and acquire credential of the client.
>
> I assumed the best place to initialize the module is just after the
> initialize_acl() invocation, if ESP is available.
> We have not discussed about this hook yet. So, I'd like to see any
> comments.

Aren't modules given a __PG_Init or something similar that they can
define which will be called when the module is loaded..?

Stephen
From: KaiGai Kohei on 14 Jun 2010 07:12
(2010/06/14 20:01), Stephen Frost wrote:
> * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
>> The attached patch tries to add one more security hook on the
>> initialization of PostgreSQL instance (InitPostgres()).
>>
>> It gives the external security module a chance to initialize itself,
>> and acquire credential of the client.
>>
>> I assumed the best place to initialize the module is just after the
>> initialize_acl() invocation, if ESP is available.
>> We have not discussed about this hook yet. So, I'd like to see any
>> comments.
>
> Aren't modules given a __PG_Init or something similar that they can
> define which will be called when the module is loaded..?
>
I assume the security module shall be loaded within 'shared_preload_libraries',
because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting using
connection string, so it allows users to bypass security features, doesn't it?

Thanks,
--
KaiGai Kohei <kaigai(a)kaigai.gr.jp>

--
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 08:15
2010/6/14 KaiGai Kohei <kaigai(a)kaigai.gr.jp>:
> (2010/06/14 20:01), Stephen Frost wrote:
>> * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
>>> The attached patch tries to add one more security hook on the
>>> initialization of PostgreSQL instance (InitPostgres()).
>>>
>>> It gives the external security module a chance to initialize itself,
>>> and acquire credential of the client.
>>>
>>> I assumed the best place to initialize the module is just after the
>>> initialize_acl() invocation, if ESP is available.
>>> We have not discussed about this hook yet. So, I'd like to see any
>>> comments.
>>
>> Aren't modules given a __PG_Init or something similar that they can
>> define which will be called when the module is loaded..?
>>
> I assume the security module shall be loaded within 'shared_preload_libraries',
> because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting using
> connection string, so it allows users to bypass security features, doesn't it?

Yeah, but so what? Stephen's point is still valid.

--
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 19:54
(2010/06/14 21:15), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei<kaigai(a)kaigai.gr.jp>:
>> (2010/06/14 20:01), Stephen Frost wrote:
>>> * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
>>>> The attached patch tries to add one more security hook on the
>>>> initialization of PostgreSQL instance (InitPostgres()).
>>>>
>>>> It gives the external security module a chance to initialize itself,
>>>> and acquire credential of the client.
>>>>
>>>> I assumed the best place to initialize the module is just after the
>>>> initialize_acl() invocation, if ESP is available.
>>>> We have not discussed about this hook yet. So, I'd like to see any
>>>> comments.
>>>
>>> Aren't modules given a __PG_Init or something similar that they can
>>> define which will be called when the module is loaded..?
>>>
>> I assume the security module shall be loaded within 'shared_preload_libraries',
>> because we can overwrite 'local_preload_libraries' (PGC_BACKEND) setting using
>> connection string, so it allows users to bypass security features, doesn't it?
>
> 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.

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 20:22
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.

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

 |  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