On 08/14/2012 05:03 PM, Michael Braun wrote:
Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on th
Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on the radius host system. E.g. to be able
to authent
On Wed, Nov 2, 2011 at 3:27 PM, Andrew Dunstan wrote:
> Patch with a small docs addition also. Adding to Nov commitfest.
I have reviewed this and it looks good to me. Marking Ready for Committer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Se
On 09/11/2011 09:40 PM, Andrew Dunstan wrote:
On 09/09/2011 11:34 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian
wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all
groups
* Andrew Dunstan (and...@dunslane.net) wrote:
> It's NOT changing that. All this affects is how +groupname is
> treated in pg_hba.conf, i.e. do we treat every superuser there as
> being a member of every group.
Ah, sorry for the noise, that's fine (and I'm bit suprised it was a
one-liner, guess I
On 09/11/2011 10:32 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
This turns out to be a one-liner.
On Sun, Sep 11, 2011 at 10:32 PM, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> > Address problem where superusers are assumed to be members of all
>> > groups
>> >
>> > http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
>>
>> This turns out to
* Andrew Dunstan (and...@dunslane.net) wrote:
> > Address problem where superusers are assumed to be members of all groups
> >
> > http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
>
> This turns out to be a one-liner.
I really don't know that I agree with removin
On 09/09/2011 11:34 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql
Robert Haas wrote:
> On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian wrote:
> > Is this a TODO?
>
> I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian wrote:
> Is this a TODO?
I think so.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Andrew Dunstan wrote:
>
>
> On 04/07/2011 11:01 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> I thought about that. What I'd like to know is how many people actually
> >> want and use and expect the current behaviour. If it's more than a
> >> handful (which I seriously doubt) then that's p
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstan writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
Otherwise it seems mo
Andrew Dunstan writes:
> I thought about that. What I'd like to know is how many people actually
> want and use and expect the current behaviour. If it's more than a
> handful (which I seriously doubt) then that's probably the way to go.
> Otherwise it seems more trouble than it's worth.
Well,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The problem here is that if Andrew had had the opposite case (a
> positive-logic hba entry requiring membership in some group to get into
> a database), and that had locked out superusers, he'd be on the warpath
> about that too. And with a lot more reason.
On 04/07/2011 07:33 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that the
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that they apply to superuser?
I think that's just about g
On 04/07/2011 03:48 AM, Alastair Turner wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more re
On Thu, Apr 7, 2011 at 6:49 AM, Andrew Dunstan wrote:
>
> On 04/07/2011 12:29 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>>>
>>> On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
>
> The surprising (to me) consequence was that
On 04/07/2011 12:29 AM, Tom Lane wrote:
Robert Haas writes:
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising (to me) consequence was that every superuser was
locked out of the system. I had not granted them (or anyone) the
ro
> The problem here is that if Andrew had had the opposite case (a
> positive-logic hba entry requiring membership in some group to get into
> a database), and that had locked out superusers, he'd be on the warpath
> about that too. And with a lot more reason.
Actually, I find that behavior surpr
Robert Haas writes:
> On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
>> * Andrew Dunstan (and...@dunslane.net) wrote:
>>> The surprising (to me) consequence was that every superuser was
>>> locked out of the system. I had not granted them (or anyone) the
>>> role, but nevertheless these lin
> See bug #5763, and subsequent emails. Short version: Tom argued it
> wasn't a bug; Peter and I felt that it was.
Add my vote: it's a bug.
Users who fall afoul of this will spend *hours* trying to debug this
before they stumble on the correct answer. pg_hba.conf is confusing
enough as it is.
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> The surprising (to me) consequence was that every superuser was
>> locked out of the system. I had not granted them (or anyone) the
>> role, but nevertheless these lines took effect.
>
> As I re
* Andrew Dunstan (and...@dunslane.net) wrote:
> The surprising (to me) consequence was that every superuser was
> locked out of the system. I had not granted them (or anyone) the
> role, but nevertheless these lines took effect.
As I recall, the way we allow superusers to set role to other roles i
I just hit this, which at least violated my sense of least astonishment,
if it's not an outright bug:
After creating a role foo, I added to following lines to my (9.0)
pg_hba.conf:
localall +foo reject
host all +foo 0.0.0.0/0 reject
The surprising (to me) consequenc
26 matches
Mail list logo
