From: Robert Haas on
On Thu, Jul 8, 2010 at 10:48 AM, Stephen Frost <sfrost(a)snowman.net> wrote:
> * Robert Haas (robertmhaas(a)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
> general catalog is something that, if we figure out a sane way to
> do it, we could always add later (if there's demand, etc).
>
> For those bits of the catalog which *do* meet the requirements you
> mention, I hope it'll be possible for the security module to access
> them? �Does make me wonder if we might consider adding a field to those
> to support a label rather than trying to figure out a way for a third
> party to provide a shared/nailed relation.

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.

--
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
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost <sfrost(a)snowman.net> wrote:
> * Stephen Frost (sfrost(a)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 realize it's come a bit far-afield from
>> your original proposal.
>
> 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 login attempts. �I wonder
> if we could add this hook (or maybe have more than one if necessary) in
> a way to support a contrib module for that.

Seems like the hard part would be figuring out where to store the
bookkeeping information.

--
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
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost <sfrost(a)snowman.net> wrote:
> * Robert Haas (robertmhaas(a)gmail.com) wrote:
>> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost <sfrost(a)snowman.net> 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 login attempts. �I wonder
>> > if we could add this hook (or maybe have more than one if necessary) in
>> > a way to support a contrib module for that.
>>
>> Seems like the hard part would be figuring out where to store the
>> bookkeeping information.
>
> pam_tally does it in a flat file on-disk. �It's not perfect, but it
> works. �It'd be good enough for me if there was a hook in the right
> place that I could write the contrib module.
>
> Of course, it'd be even nicer to have support for this in-core, since
> it's a FISMA requirement and not everyone is going to like having to
> install a contrib module to handle something like this.

Feel free to propose a patch...!

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