(2010/07/09 23:52), Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Guess my first thought was that you'd have a database-level label that
>> would be used by SELinux to validate a connection. A second thought is
>> labels for roles. KaiGai, can you provide your thoughts on
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
>> > Something else which has come up but is related is the ability to
>> > support a "pam_tally"-like function in PG. Basically, the abil
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
> > Something else which has come up but is related is the ability to
> > support a "pam_tally"-like function in PG. Basically, the ability to
> > lock users out if they've had too many failed log
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Guess my first thought was that you'd have a database-level label that
>> would be used by SELinux to validate a connection. A second thought is
>> labels for roles. KaiGai, can you provide you
* Stephen Frost (sfr...@snowman.net) wrote:
> Guess my first thought was that you'd have a database-level label that
> would be used by SELinux to validate a connection. A second thought is
> labels for roles. KaiGai, can you provide your thoughts on this
> discussion/approach/problems? I realiz
(2010/07/08 23:58), Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I'm not sure what the best thing to do about this is. I think it
>> might be a good idea to start with some discussion of what problems
>> people are trying to solve (hopefully N> 1?) and then try to figure
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm not sure what the best thing to do about this is. I think it
> might be a good idea to start with some discussion of what problems
> people are trying to solve (hopefully N > 1?) and then try to figure
> out what a good solution might look like.
On Thu, Jul 8, 2010 at 10:48 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> 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.
>
> I feel t
* Robert Haas (robertmh...@gmail.com) wrote:
> 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.
I feel that would be perfect for 9.1 and supporting access to the
gener
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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 b
On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost 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.
>
>
Stephen Frost writes:
> * Robert Haas (robertmh...@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 securi
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/16 KaiGai Kohei :
> > 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
2010/6/16 KaiGai Kohei :
> 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://commi
(2010/06/16 21:37), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> 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.
> [...]
>> However, here
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> 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.
[...]
> However, here is no hooks available for the purpose.
I believe we
(2010/06/15 21:37), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@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
On Tue, Jun 15, 2010 at 8:37 AM, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@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 addition
KaiGai,
* KaiGai Kohei (kai...@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)
(2010/06/15 12:47), KaiGai Kohei wrote:
> (2010/06/15 12:28), Tom Lane wrote:
>> KaiGai Kohei 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.
>>
(2010/06/15 12:28), Tom Lane wrote:
> KaiGai Kohei 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 con
KaiGai Kohei 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 t
(2010/06/15 10:12), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> (2010/06/15 9:22), Robert Haas wrote:
>>> 2010/6/14 KaiGai Kohei:
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
2010/6/14 KaiGai Kohei :
> (2010/06/15 9:22), Robert Haas wrote:
>> 2010/6/14 KaiGai Kohei:
>>> 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.
(2010/06/15 9:22), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> 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 getpee
2010/6/14 KaiGai Kohei :
> 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
(2010/06/14 21:15), Robert Haas wrote:
> 2010/6/14 KaiGai Kohei:
>> (2010/06/14 20:01), Stephen Frost wrote:
>>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
It
2010/6/14 KaiGai Kohei :
> (2010/06/14 20:01), Stephen Frost wrote:
>> * KaiGai Kohei (kai...@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
(2010/06/14 20:01), Stephen Frost wrote:
> * KaiGai Kohei (kai...@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 acqui
* KaiGai Kohei (kai...@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
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
init
31 matches
Mail list logo
